Parts of this blog, including the code examples and architecture frameworks, were generated using Keyhole Software’s EnterpriseGPT web client—an open-source tool that empowers organizations to deploy user-friendly chatbot solutions with ease. Interested in exploring further? Contact our team, and we’d be happy to provide credentials for you to try it out. The Rise of Python and Other Languages We’ve seen …
Attention: This article was published over 2 years ago, and the information provided may be aged or outdated. While some topics are evergreen, technology moves fast, so please keep that in mind as you read the post.In the latest episode of Next Level, Zach has the pleasure of chatting with Tom Hill, Engineering Director at Corsearch, about his career journey …
In this post, I am going to demonstrate how to set up a simple Next.js web application. Next.js is a heavily opinionated JavaScript framework, in that it has a lot of conventions and recommended tools built into its design.
We’ll use Next.js version 14.2.2 to set up the groundwork for a simple web application. By “web application,” I mean an application that is designed primarily to collect input from a user in a web browser and return some output generated from that input.
Attention: This article was published over 2 years ago, and the information provided may be aged or outdated. While some topics are evergreen, technology moves fast, so please keep that in mind as you read the post.In Minneapolis, there are ten software development companies that standout: Keyhole Software, THE NERDERY LLC, Emergent Software, Bitwise IO, Improving Company, MentorMate, Coherent Solutions, …
I’ve been developing JavaScript through all of the major existential changes we’ve had. Browser wars? I remember those. Trying to make a complex application before Firebug? Oh yeah, tell me about it. Having to roll my own AJAX request by hand? Vividly remember.
Something that I experienced in all of my large JS projects before the last few years was an eventual point of no return, a metaphorical event horizon, beyond which the amount of time it took to build the code locally as well as on the CI/CD system was just simply too long.
All projects start fine, but as they grow and evolve and change over time, the amount of build time seems to creep up until it becomes inimical to deploying and testing changes in any reasonable time frame. Further, it becomes very difficult to onboard new developers as any change they make is not isolated, and must take into account all of the other code in the app. Granted, frameworks and libraries like React do help to some extent, but there are no clean-cut boundaries on the source code with different features, it always had to be by convention.
It was during a project a few years ago that I finally put my foot down and decided that something needed to be done. Researching how other architects were doing it, I came across JavaScript monorepos. I was familiar with the concept of monorepos from my research on how Google structures their code base (they have two repos, one for YouTube and one for everything else, no joke), but had never thought to apply that same principle to JavaScript. So I dove in head first, made a lot of mistakes, iterated, and finally got to a place where I feel comfortable sharing my lessons learned.
This blog post is not an extensive study, but it is enough to get you interested in a way to solve two common problems we all have (i.e. sluggish build times and inability to effectively onboard new devs due to lack of feature separation), and give you enough of a context around how I approached the problem to determine how you should proceed.