SovTech is now Scrums.com!!
Read more here
Issue #4 – Poly Hack – HTTP3 – Lambda Workflows
The typical full-stack application is made up of a lot of JavaScript. This has made applications a lot bigger than they used to be. As a result, long build times and deployment fails because your app is too big, which will be something you deal with one day (if you haven’t already).
Read about the time Uber almost failed to launch their IOS app in 2016.
Every time a user interacts with your app, the CSS and Javascript (and any other files) is provided to the browser as a bundle. Bundlers like Webpack and Parcel do most of the work in minifying your application packages. But that is not always enough, here are some ways you can go about keeping your build files small:
Code elimination & tree shaking – As mentioned above, your bundler does some work dropping unused code. Unfortunately, this doesn’t always fully do the job; you can read about how you can perform tree shaking practices in your JS app here.
Library alternatives – NanoID vs UUID, datefns vs moment. Large library packages increase your build size by a big amount. Luckily with a rich ecosystem, most of the time, you can find a smaller package that does a better job.
Code Splitting/Lazy Loading – Code splitting gives you the ability to create a bundle that will be separate from your main one. Lazy loading then allows you to load that newly created when your application needs it.
devDependencies – Your main dependencies are required to run your application in production. However, as frequently forgotten about packages like Typescript definitions or Linters can sometimes be large. These packages are meant for development and belong as dev dependencies.
Here is a StackOverflow post that adds on; you can also read about adding in performant practices relating to typescript here.
Although this was meant to be a breakdown of a case study: how Devsisters built a world-class game with over 10 million downloads on CockroachDB, the tech the article is based on, also quickly steals the show—trying to solve the challenge presented by the CAP theorem, Ex-Googlers and exciting applications in a wide range of industries.
Appropriately referred to as “the database that just won’t die” and created by three former google engineers. CockroachDB was designed to be a database that allowed you to write data and immediately made it available a thousand miles away.
Overall this database has seen wide adoption in enterprise applications during Covid, given how it handles data partitions, speed and isn’t priced high. Every now and then, a database that sells itself on being the future of storage is introduced; CockroachDB seems to be one of the few that can back these claims.
You might be aware of the large amount of time that could go to setting up build and deploy pipelines. AWS CodeStar is a managed service that tries to solve this issue, giving you a collection of existing AWS services that make it easier to develop and deploy your applications.
AWS CodeCommit acts as your git repository.
CodeBuild is responsible for continuous integration, testing and building your application before deployment.
CodeDeploy will automate your deployments.
Finally, CodePipeline is the glue that sticks everything together, allowing you to visualise each step in the build process.
Frontend tech is getting a lot more exciting to explore with every passing week. Although beta was only released a month ago, it’s still not too late to introduce Astro, the static page builder. 100% HTML, Bring your own framework (React, Vue, Web components, etc.) and full support for tools like typescript and CSS modules.
The team that has done such a good job selling to developers graphql implementation (we almost assume it’s the only platform) has released Apollo server 3.
We haven’t forgotten that billionaires in space are now a thing. Let’s revisit this StackExchange post reminding us of how web components (Chromium + JS) were used in the Dragon 2 flight interface.
