are normally divided right into a separate frontend and backend. The frontend handles what the consumer sees, whereas the backend handles all the logic and processing. It is a pure separation of issues that almost all platforms merely use as a result of it really works effectively.
Nevertheless, while you make adjustments to your software, you typically have to make adjustments to each the frontend and the backend. That is the place full-stack engineers are available in: engineers who work with each the frontend and backend.
Working with each frontend and backend will be difficult, nonetheless, because of a number of causes:
- They’re typically written in numerous languages: frontend with TypeScript and the backend with Python
- You must take care of permissions and auth, and take care of challenges like CORS errors
- They’re in numerous repositories and are deployed individually.
With the discharge of coding brokers, working with each frontend and backend code on the identical time has turn into easier. On this article, I’ll offer you a high-level overview of how I work every day with each frontend and backend code, and ensure the 2 techniques combine seamlessly.
Why work with each frontend and backend
The rationale you’re employed with each frontend and backend code on the identical time is just due to necessity. Let’s say you wish to add a brand new characteristic in your software, the place a consumer can retailer their AI chatbot conversations and entry them later.
This characteristic merely requires adjustments in each the frontend and the backend. It’s good 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 in case you needed to implement the AI chatbot conversations characteristic, and also you had been solely engaged on the frontend. You’ll then must implement the frontend a part of the course, after which coordinate with one other backend engineer on methods to retailer the conversations. You’d must spend time discussing:
- The schema for storing conversations
- Which information must be included?
- What ought to the endpoint be known as
That is tremendous time-consuming. If you happen to’ve ever labored in a processional software program engineering setting, you understand how a lot time it takes.
As an alternative, in case you do the work solo, you don’t must do any coordination and might transfer at a a lot better pace.
Strategies to work successfully with frontend and backend code
On this part, I’ll cowl some strategies I exploit to work successfully with each frontend and backend code. With the discharge of a super-effective coding agent, this has turn into a lot easier, and also you don’t have to have in depth expertise in each frontend and backend code to be efficient.
Use Workspaces
Workspaces are an extremely highly effective characteristic when working in a number of repositories. You are able to do this with Cursor utilizing “Add workspace”, or with any CLI instrument by merely pointing the agent to the repositories you wish to work with. Now the mannequin can have the context of each related repositories and thus be capable of implement a full-stack answer in a single go.
Workspaces are unbelievable. 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 just 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 accordance with some directions, and it mechanically updates the backend with the corresponding code to just accept the frontend adjustments. After all, this works the opposite approach as effectively.
Monorepos
Monorepos are additionally tremendous highly effective. The other of a monorepo is to have all your code unfold into totally different repositories (normally known as microservices). In my expertise, this doesn’t work very effectively, because it merely makes it more durable for you and your coding brokers to maintain observe of the place the whole lot is.
As an alternative, I extremely suggest shifting the whole lot to a monorepo, the place you could have all of your code in a single codebase. Now you may simply create guidelines, corresponding to pre-commit hooks, that apply to all your code and should not have to duplicate them throughout a number of repositories. Moreover, you may simply have AGENTS.md recordsdata masking and explaining the entire repository, so brokers simply maintain observe of the place the whole lot is.
If all of your code is in a monorepo, you’d additionally not want workspaces, as I described within the final part. Nevertheless, it’s fairly widespread to have a monorepo for the frontend/API code, after which a separate repository dealing with extra advanced processing, corresponding to working brokers or doing doc processing. Thus, you’ll typically have to make use of workspaces anyway.
AGENTS.md as context
One other crucial tip is to actively use and replace AGENTS.md. There are a lot of alternate options to AGENTS.MD, corresponding to CLAUDE.md, WARP.md, or .cursorrules. In my expertise, nonetheless, AGENTS.MD is learn by all coding brokers, regardless of which one you utilize.
Thus I like to recommend utilizing AGENTS.md as a result of in case you ever change an agent sooner or later, or your coworkers are utilizing totally different brokers, you may all profit equally.
You’ll be able to 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 include which logic, making it simpler for the agent to navigate the code.
Moreover, you may have AGENT.md in all subfolders as effectively. For instance, when you’ve got a service in a single folder, you would have an AGENTS.md file there explaining how the service works, or any quirks to concentrate on.
I additionally wish to add that everytime you make adjustments to your code, make sure to replace AGENTS.md. You’ll be able to, for instance, immediate your coding agent to replace the related AGENTS.md recordsdata for you, given what it discovered in its final session, and it’ll mechanically add necessary notes. Be sure you push these adjustments to GitHub as effectively, in fact, so your colleagues can profit from the information you’ve gained.
Conclusion
On this article, I’ve mentioned methods to successfully work with each frontend and backend code. I began off by explaining why it’s necessary to know methods to work with each frontend and backend, highlighting that it’s normally a more practical approach of getting stuff executed. Moreover, I elaborated on some strategies I exploit to work successfully with frontend and backend, masking the usage of Workspaces, monorepos, and AGENTS.md. I imagine 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 approach potential, with a purpose to clear up crucial issues, in the perfect 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
