I have the pleasure of working for IT Minds under the guise of a Senior Software Developer. In short, I am one of the people with technological responsibilities across the board.
One of my core responsibilities is helping our customers find the best solution to their needs.
From the very first meeting until the last handshake, I will be the primary technical responsible party.
My first task is to listen to the customer, their technical requirements, limitations, and wishes - and from there present a solution architecture that fits all the criteria. More often than not these vary from company to company.
However, when it comes to web applications I do have a go-to tech stack that I pitch and showcase as an example. And I thought I would share it with you all.
My Go-To Stack consists of the main areas and services.
- The Datacore,
- The Micro(nano) Services
- The User Client
cd ./data-core
The responsibility for this area primarily lies with building a data model, serving said model and expose the means to change the data.
This is generally achieved with a Typescript Node service. Using GraphQL as the main API for external communications.
I love GraphQL. Whenever I build a data model with REST I tend to always get lost in all the ViewModel, DTOs, Data Entities and logic models. For the most part, all these aspects of the same concept are redundant. Each of the aforementioned aspects serves a great purpose.
When I take a look at what I need it always ends up with, serving data and allowing changes to data. This is where GraphQLs streamlined 'Queries' and 'Mutations' come into play.
I build my data model with Typeorm and Type-GraphQL with Postgresql as the database.
To bind it all together I serve this service via Apollo.
cd ../nano-services
I cannot get enough of the serverless approach. Utilize the platform is a concept I am all about. It fits in so many places.
I keep all the more 'important' logic out of my datacore. Important concepts like authentication, authorization, logging, queuing, caching, etc. are all part of the business logic - but not the actual model (for the most part).
And so I write all of this "middleware" with a serverless approach.
NextJS(X) is fantastic when it comes to a lightweight serverless api. It isn't "platform-specific" but still as powerful as the big guys' serverless options.
I keep a MongoDB in the tool belt for this service, should there be a need for storing data relevant to the mentioned concepts.
cd ../user-client
While sometimes overlooked, I cannot stretch the importance of a good experience for the user and developer when it comes to developing a client for the user.
I love React and React Hooks. And already using NextJS for the serverless it is a no-brainer to pitch it for the user-client.
Apollo Client allows for a built-in data concept 100% aligned with the data available and served by the datacore.
NextJS makes having the site PWA and AMP per default an easy thing.
cd ..
Many people aren't fans of JavaScript and to alleviate some of the developer pains I use Typescript across the entire stack. That way I can ensure strong safe typing between all interfaces.
Here is what the overall product would look like
When done correctly, a good amount of buzzwords is healthy during a pitch. So with this tech stack you can show off saying that the end product will be a:
Isomorphic Serverless Progressive "Mobile Accelerated" Lightweight Web Application with a very horizontal scablable backend.
Thank you for reading. I hope to provide some examples or possibly template for all this talk in the near future. Let's see how much time my boss gives me :3
You have been lovely! See you in the comments!
You can also see the stack @ stackshare
Top comments (4)
About your back-end stack (typeORM, type-graphQL, postgreSQL), is there a particular road you'd encourage (or discourage) one should take to set up a easily maintainable, scalable and stable back-end?
I've experimented with using custom typeORM-repositories, and defining the datamodel in a single place (so a single file), to be used by both typeORM and type-graphQL using TypeScript decorators. I'm not sure if this level of abstraction is still maintainable in the long term, for larger production-grade applications.
Any other advice to give?
Thanks in advance.
edit: The goal of the thing I'm trying to set-up is a side-project, so experimenting is perfectly fine.
I will say this - generics MIGHT be a solution.
Some time ago I thought to myself "mhh, all of these repositories with the same bland crud options are getting old, why not just DRY it with generics" - a thought I wish I never had. Right now I am sitting on top of a project built using generics repositories to all my entities, I also have generics resolvers for graphql.
It is all good until the data model varies just a little bit and the relationships become more advances.
So I would suggest trying generics out - but do not rely upon it.
My own structure is this
Entities are classes that use both typeorm and typegrapql decorators for creating the queryable and the domain models.
My inputs are my "DTOs". My own rule is that any mutation must not have an entity as input.
Types are the home of my more general return types, inputs, and scalars.
For example, I have created a Generic paging result that takes in an input extending an entity. The purpose of being able to have a method for all my queries with the same structure when it comes to paging, sorting, and filtering.
Like I said in my main post - I hope to soon provide some code as examples, I just need to have something that isn't for a client. Aka my boss needs to give me some free hours :3
So far I haven't tried out generic repositories, since I already experienced that having a custom repository for every entity is much more powerful than having a single repository usable by all entities.
I'm a real fan of customizability over reusability, something that is a pain in the rear to set up and maintain, but really rewarding in the long-term, to prevent that a piece of software totally lacks freedom and susceptibility to change. All the testing frameworks that exist nowadays will perfectly keep an eye on any breaking changes, if set up correctly.
And I sincerely hope your boss acknowledges your need and gives you some time to prepare some code examples, I would love to look into those!
You still use the same stack?
I actually use exactly the same trio (Type-graphQL, typeORM and PSQL) in my webapps! I am currently studying CS, so working at IT-minds would be amazing, and even more so if you already use my favorite tools :D