are normally divided right into a separate frontend and backend. The frontend handles what the person sees, whereas the backend handles the entire logic and processing. This can be a pure separation of issues that almost all platforms merely use as a result of it really works nicely.
Nonetheless, whenever you make modifications to your utility, you typically have to make modifications to each the frontend and the backend. That is the place full-stack engineers are available: engineers who work with each the frontend and backend.
Working with each frontend and backend could be difficult, nonetheless, on account of a number of causes:
- They’re typically written in several languages: frontend with TypeScript and the backend with Python
- It’s important to cope with permissions and auth, and cope with challenges like CORS errors
- They’re in several repositories and are deployed individually.
With the discharge of coding brokers, working with each frontend and backend code on the identical time has change into easier. On this article, I’ll offer you a high-level overview of how I work each day with each frontend and backend code, and ensure the 2 methods combine seamlessly.
Why work with each frontend and backend
The explanation you’re employed with each frontend and backend code on the identical time is solely due to necessity. Let’s say you need to add a brand new function in your utility, the place a person can retailer their AI chatbot conversations and entry them later.
This function merely requires modifications in each the frontend and the backend. It’s essential to replace the frontend to show the earlier conversations, and also you want the backend to deal with the storage and retrieval of conversations. Thus, you don’t have an choice to work with each the frontend and backend code.
Moreover, as an engineer, it’s normally more practical to work with each frontend and backend. Think about if you happen to needed to implement the AI chatbot conversations function, and also you had been solely engaged on the frontend. You’ll then need to implement the frontend a part of the course, after which coordinate with one other backend engineer on the way to retailer the conversations. You’d need to spend time discussing:
- The schema for storing conversations
- Which information ought to be included?
- What ought to the endpoint be known as
That is tremendous time-consuming. When you’ve ever labored in a processional software program engineering setting, you understand how a lot time it takes.
As an alternative, if you happen to do the work solo, you don’t need to do any coordination and may transfer at a a lot higher pace.
Strategies to work successfully with frontend and backend code
On this part, I’ll cowl some methods I exploit to work successfully with each frontend and backend code. With the discharge of a super-effective coding agent, this has change into a lot easier, and also you don’t have to have intensive expertise in each frontend and backend code to be efficient.
Use Workspaces
Workspaces are an extremely highly effective function when working in a number of repositories. You are able to do this with Cursor utilizing “Add workspace”, or with any CLI device by merely pointing the agent to the repositories you need to work with. Now the mannequin may have the context of each related repositories and thus have the ability to implement a full-stack resolution in a single go.
Workspaces are unimaginable. Earlier than I found it, I used to work with two separate Cursor tabs, one with the frontend code and one with the backend code. I’d then make one change within the frontend, and manually replace the backend to simply accept this new change.
No surprise it took ages for me to place out options. Now, I merely immediate my agent to replace the frontend in line with some directions, and it mechanically updates the backend with the corresponding code to simply accept the frontend modifications. In fact, this works the opposite method as nicely.
Monorepos
Monorepos are additionally tremendous highly effective. The other of a monorepo is to have your whole code unfold into totally different repositories (normally known as microservices). In my expertise, this doesn’t work very nicely, because it merely makes it more durable for you and your coding brokers to maintain monitor of the place every part is.
As an alternative, I extremely advocate transferring every part to a monorepo, the place you’ve all of your code in a single codebase. Now you may simply create guidelines, comparable to pre-commit hooks, that apply to your whole code and shouldn’t have to duplicate them throughout a number of repositories. Moreover, you may simply have AGENTS.md recordsdata protecting and explaining the entire repository, so brokers simply preserve monitor of the place every part is.
If all of your code is in a monorepo, you’d additionally not want workspaces, as I described within the final part. Nonetheless, it’s fairly widespread to have a monorepo for the frontend/API code, after which a separate repository dealing with extra complicated processing, comparable to operating brokers or doing doc processing. Thus, you’ll typically have to make use of workspaces anyway.
AGENTS.md as context
One other essential tip is to actively use and replace AGENTS.md. There are lots of alternate options to AGENTS.MD, comparable to CLAUDE.md, WARP.md, or .cursorrules. In my expertise, nonetheless, AGENTS.MD is learn by all coding brokers, irrespective of which one you utilize.
Thus I like to recommend utilizing AGENTS.md as a result of if you happen to ever change an agent sooner or later, or your coworkers are utilizing totally different brokers, you may all profit equally.
You may have an AGENTS.md file within the root of your repository that gives a high-level overview of the repository, sort of like a README. This will clarify to the agent which folders comprise which logic, making it simpler for the agent to navigate the code.
Moreover, you may have AGENT.md in all subfolders as nicely. For instance, when you have a service in a single folder, you can have an AGENTS.md file there explaining how the service works, or any quirks to pay attention to.
I additionally need to add that everytime you make modifications to your code, remember to replace AGENTS.md. You may, for instance, immediate your coding agent to replace the related AGENTS.md recordsdata for you, given what it realized in its final session, and it’ll mechanically add vital notes. Make sure to push these modifications to GitHub as nicely, in fact, so your colleagues can profit from the information you’ve gained.
Conclusion
On this article, I’ve mentioned the way to successfully work with each frontend and backend code. I began off by explaining why it’s vital to know the way to work with each frontend and backend, highlighting that it’s normally a more practical method of getting stuff performed. Moreover, I elaborated on some methods I exploit to work successfully with frontend and backend, protecting the usage of Workspaces, monorepos, and AGENTS.md. I consider that sooner or later, we’ll all be full-stack engineers, contemplating how efficient coding brokers are. The work of a human engineer will merely be to coordinate all of your brokers in the simplest method doable, to be able to clear up crucial issues, in the very best and most effective method.
👉 My free eBook and Webinar:
🚀 10x Your Engineering with LLMs (Free 3-Day Email Course)
📚 Get my free Vision Language Models ebook
💻 My webinar on Vision Language Models
👉 Discover me on socials:
💌 Substack
