Decentralized Fullstack development in 2022

Welcome folks! Hope 2022 is going to be a great year for all of you. Today I wanted to share my thoughts on Fullstack development, how’s its evolved over the years and what the current state of decentralized fullstack development looks like.

Infamous Fullstack developer

Whether its for hiring for a new position or someone fresh off a bootcamp wanting to get their hands dirty, a lot of folks gravitate towards Fullstack development. The problem is the role and responsibilities of a Fullstack developer is not well defined (some even call it a buzz word) and needs more clarity on what a Fullstack developer does and how to pick up skills to get better at it.

Earlier before Netflix and decentralized microservice architecture, things were more monolithic and big systems that ran multiple components like the website, transaction processor, blogs, etc. When it went down everything went down with it, you probably heard stories about why it’s not a good idea to scale with a monolithic system. Fullstack for those apps meant learning either the LAMP or MEAN stack and being able to juggle features and maintainability between those components.

But this also meant their tech stack was also quite lean since it’s difficult to have 7 different languages and tools to do the same thing. So Fullstack meant working on the Frontend and Backend side of things while also updating and optimizing the persistence layer like caches, queues and databases. Simple right, while not easy it was a lot more easily to tell apart the requirements for being a Fullstack developer than a Backend or Frontend developer.

It also allows greater flexibility in terms of being more creative as well as building a streamlined backend for serving the users. The barrier of entry is relatively high, in order to be an effective fullstack developer, you need to know their backend and frontend well enough to dive into both. Every one who does fullstack has a preference on which side they like better, but it’s is super cool to work on a feature from start to end delivering it to the user.

Decentralized Fullstack developer

A decentralized fullstack developer has to be able to work on with the previous skillsets but also needs to be more familiar with each roles and how these roles interact with each other (example, to fetch or update account information). Decentralization offers greater benefits for scaling and having resilient services but also requires a deeper understanding of how the roles or services are connected to each other.

Tracing and monitoring

Another issue with being a fullstack developer in a distributed system is that both the backend and frontend are fragmented into microservices and microfrontends, and would need a to know a lot on how theses features/pages route requests within the internal network.

Here’s an example Nginx used when comparing the benefits and complexities added when moving from a monolith to distributed set of systems. Highly recommend checkout out their blog post where they go in much more detail on how to get a better balance on getting microservices configured correctly to scale.

Compared to the microservices architecture using REST APIs and routing user requests within the new network.

For building fullstack features you would need to know the lifecycle or flow of user requests within the system and best way to implement them in the microservices architecture. That’s why I feel being a fullstack developer has become more difficult in a distributed setup, however it’s still a great opportunity to learn, grow and become the jedi navigating the microservices galaxy of the future.

Luckily there are a few tools based on OpenTracing specs to track the journey of a request into the services realm.

• Jaeger Tracing
• OpenCensus
• Zipkin

Persistence layer implementation

With interconnected services having a caches, message queues and databases are pretty common to optimize for and store stateful information. For relational databases it also becomes important to think on how to best partition the information to avoid data loss and optimize slow queries and performance. While this only becomes a sticking point with large sets of data and joined tables to fetch information, it’s needed to be able to store and retrieve data effectively from databases or key value stores like Redis.

Message queues are widely used to pass key event information between services and microservices. For example, when a user signs up for a service, a message is sent to a message queue to notify other services that a new user has signed up.

Build and testing

Build and testing tools are dependant on the language of choice. Node/Typescript have excellent tools and libraries to make it easier to build and test. That being said no matter the choice of language or tools, it’s important to decouple Frontend and Backend build and test processes to allow greater flexibility and to ensure they can be deployed independently. Having an automated build and test pipeline will help in ensure both Frontend and backend is well tested and easier to create new builds or images for deployments.

Dockerization and deployment

Having the local environment running in a docker container is a great way to test and develop your microservices. It ensures the same environment is used to setting these services and isolates them from each other. Another added benefit of using a dockerized app is the built in caching can help shave off minutes from the build times.

One thing to consider when choosing a deployment method, you can either setup Push or Pull type deployment pipelines that can help deploy your changes onto different environments. Although both Frontend and backend services can be setup to run in a push or pull type.

The Frontend / UI stands to benefit the most from Pull deploys in which case, if a website has been updated, the browser can poll for any new changes and notify the user to reload or fetch the newest changes. Push deploys are more intentional and need it to be configured with the right params inorder to test and deploy your changes. This is generally ideal for backend type changes although it can be modified to run for specific protected branches.

Conclusion

That wraps it up, hope you enjoyed reading my thoughts on Fullstack development and how it’s evolving over the years. While writing this post, it helped me understand which parts I need to grow in to be a full fledged Fullstack developer. Also hope it provides you with a good starting point if you want to learn more on how to become a Fullstack developer or if you want to specialize in a specific areas in the massive tech ecosystems (they’re kinda like mini-galaxies within themselves).

Replicated computing

Oh one last thing, if you’re curious about Web3 standards and how they can move the internet to a truly decentralized system (interaction on blockchains) with no single dependence on AWS or major ISP providers check out this ethereum blog post. I also find it fascinating how we have moved from Monolith to Microservices to now replicated computing (Proof of Work / Stake / History) to achieve resilience at scale.