This repository has been archived by the owner on May 21, 2024. It is now read-only.
Initial motivation #76
denis-ilchishin
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The motivation behind Neemata:
I’ve been working with different technologies and frameworks, like Express, Fastify, Nest, tRPC, Django, Flask, gRPC, Laravel, and some other. Most of them provide very nice experience for solving some specific tasks. Some of them, like Nest, try to solve virtually every possible problem you could come across. Some of them require you to follow “their” way to do things. Some of them are pretty much simple web servers, providing little abstraction on top of HTTP.
For some context
Most projects, I’ve been working on, were not well defined in terms of business requirements. Some of them were startups. Really often I receive some new requirements just the few days after I receive an approval to start work on some feature/changes (sometimes after long discussions). Unfortunately, that’s my reality and what I have to work with.
Also, I’ve found out that most projects I’ve been working on have quite a lot of similar necessities:
Why not just use Nest?
Complete, backed by huge community, battle-proofed architectural approaches.
In the end, in my opinion, Nest is very nice choice for larger teams, with larger amount of resources, and well-defined business requirements and good engineers on board to build complex solutions. It has some way/solution to wide spectrum of problems you could come across, as well as quite impressive amount of first-party integrations with other technologies/frameworks/services. But it still is a disaster for small teams and product MVPs, as the development speed slows down dramatically.
Why not Fastify then?
Lightweight, backed by great open source developers like Matteo Collina, and large community.
Then just use tRPC, goddamnit.
Why use JS at the first place?
Well, because it is a very flexable, multi paradigm language. Due to its loosey goosey nature, it suits very good for prototyping and MVPs.
So, here the things I’d like to have from my tool:
How Neemata solves (or plans to solve) these problem:
Minimizing boilerplate by using declarative loaders and code generation.Giving up on this: Introduce modules #104Who could be interesting in Neemata? (Theoretical story of your success)
Project where you have to move fast, because it still "finding itself". At the beginning you just need to quickly bootstrap simple API endpoints with basic input validation. You add a web client also written with JS/TS, in this case you can just statically type the whole thing. Meanwhile it've grown to the degree when you need to execute some heavy (for an APIWorker) tasks, and you just spin new TaskWorker by changing one config option. At some point of time you also need to add bidi communication, and you just add additional WebsocketsTransport, and now it just works with websockets as well. You just provider a SubscriptionManager, define your server-side events and you good to go. After some time your project have grown a bit, and it seems like only one APIWorker is not enough anymore, and you just spin another one, again, just by changing config option. But you do not worry that some clients can connect to one worker, and some to another, therefore requiring some external message broker for events routing/propagation, because the app still runs within one machine and everything you do is just swap SubcriptionManager with the appropriate one provider by Neemata. Сatching a wave of success you now also need mobile app, fortunately, Neemata got you covered, because you can generate API interfaces for the native platform using JSONSchema, that can be generated from the input/output schemas you were providing with your Procedures. You, your business and your client are very happy, because everything above was done without application code even knowing it. It just worked.
At some point you might go all-in with k8s. But with Neemata, you have delayed that time as long as you could. Probably, by that time your product found much more clear/defined usecases/requirements and it also possible, that you realized that those problems could be solved much more efficiently with another technologies or even languages, like Golang, Rust, etc.
Beta Was this translation helpful? Give feedback.
All reactions