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 are helping our customers find the best solution to their needs.
From the very first meeting till 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 datamodel, 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 datamodel with REST I tend to always get lost in all the ViewModel, DTOs, Data Entities and logic models. For the most part all these aspect of the same concept are absolutely redundant. Each of the aforementioned aspects serve 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 datamodel 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 concept 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 the React Hooks. And already using NextJS for the serverless it is a nobrainer 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.
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:
Server-Side-Rendered 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
