Why your company should have an Open Source Playground
What if you could test new things, technologies, packages and approaches without break your current development workflow or end user product?
In fact you can, you just need a Playground where you can play.
When in a maximum local, you need to go to a worse solution to find a better one
What is a Playground?
When scientists want to understand or learn about something, they do not test their hypothesis in real world, they usually do experiments in a small scale representing part of the phenomenon to be studied.
In the same way, a development Playground represents a small scale of your current project setup, so you can do experiments with it.
For instance, if your project is using Node, GraphQL and Relay Modern, your playground should match this structure.
How are we using Playgrounds at Entria Tech?
Here at Entria Tech, we've being using boilerplates as our Playgrounds to test new things.
As our codebase evolve, we upgrade our playgrounds, but some times the change is too big that we move to a new playground.
Here is the current history of Entria Tech playgrounds:
- koa-passport-mongoose-graphql: backend using koa and graphql
- graphql-dataloader-boilerplate: boilerplate with best practices for a performatic GraphQL
- restria: best practices when doing REST
- entria-fullstack: our monorepo playground
Why it should be open source?
This boil down to this:
When you have an Open Source Playground you could solve issues that other people could have, and someone else could fix some of the issues. It is a Win Win relationship.
Besides, when your playground is open source you are going to polish more the code to present in public, making the code better. You can also get feedback from more developers than your company team.
Entria Fullstack Playground use case
We are moving to monorepos at Entria Tech, as we think this is the right approach to build better code, as we can easily extract common code to packages that can be reused in multiple projects and could also be open sourced more easily, we going to write more about monorepo at Entria The Tech Team in another post.
Monorepos are good, but they are hard. Everything that worked before stopped working when we moved to monorepo. So we did a checklist of what we should fix before moving our project from a multiple single repos to a monorepo:
- eslint should work
- tslint should work
- typescript typecheck should work
- babel should work
- tests should work
- building process should work
- docker build should work
- automated deploys should work
- we should be able to share packages among projects
We fixed most of the issues, and we moved in 3 monorepo for now (one for backends, one for frontends, one for apps).
We received great contributions from community that helped improve our playground and our internal code.
Vikram Rangaraj from Google Developers sent this pull request: https://github.com/entria/entria-fullstack/pull/13, fixing some jest issues when using Yarn workspaces
Matheus Silves added a web package using Webpack-plugin-serve https://github.com/entria/entria-fullstack/pull/25, a webpack package was missing to make our playground more close to our internal codebase.
Paulo Rezende sent this pull request https://github.com/entria/entria-fullstack/pull/30, adding Hot Module Reload to server packages, this made our backend development iteration very fast, as nodemon was getting to slow as we have a big codebase, we went from almost 2/3 seconds reload to just 200/300 ms on hot reload or full reload of wepback.
Thanks for all contributors \o/
What's next?
I'd like to invite you all to learn Monorepos with us.
Share your playgrounds on comments, I'd like to see in what things you are working on.
Ping me on twitter https://twitter.com/sseraphini if you need any help
Newsletter
Subscribe to my newsletter for new content https://sibelius.substack.com/
