Tech buzzwords: do you really need MongoDB, NoSQL, Next.js or a trendy stack?
MongoDB, Next.js, Symfony or PWA: understand what each component does and choose a technical stack based on your business needs, not the latest trends.
Sur cette page6 sections
"We need to go with Next.js and NoSQL." Fine. But what will your business be able to do better because of it? If the answer comes after ten minutes of technical jargon, I'd rather we start the conversation from the beginning.
I'm not against new tools. A developer has the right to enjoy trying things out. The problem starts when their desire to experiment becomes your invoice, and then your maintenance headache for years to come.
A stack is the set of technical building blocks for a project. You can choose it well without chasing every new name, and choose it poorly even with well-known technologies. The starting point must remain what needs to be built.
These terms are therefore not competing answers to a single question. A project can combine several of these blocks. Saying "we're hesitating between MongoDB and a PWA" is a bit like hesitating between a car's boot and the way it drives.
You don't have to memorise the whole dictionary. Above all, your provider should be able to explain what responsibility each block fulfils, and what makes it necessary for your project.
A relational database like MySQL lends itself to an organisation of linked tables. This is often a very readable way to represent this type of activity. With MongoDB, data is organised into documents, choosing what to group and what to reference. This approach can suit other forms of data and their uses.
It's not "rules" versus "no rules". MongoDB also allows working with relationships and transactions. Its documentation on modelling et transactions shows that the choice requires real design. Flexibility doesn't remove the need to know what you're recording, how you find it, and how you evolve it.
A product sheet that changes shape frequently might suggest studying a document model. A set of orders, invoices, and access rights can make a relational model very natural. These are avenues for thought, not rules that automatically designate a winner.
And "we will have a lot of data one day" is not yet a measure of load. Before preparing the site for millions of imaginary users, let's look at what will actually be required of it at launch.
You can use one, the other, or make them work together. The documentation for Next.js et de Symfony presents their possibilities. None of them say your quote form needs two independent applications.
Separating an interface and a back-end can be very useful. But it can also add an API to manage, multiple deployments, access between services, and more testing. The benefit must justify this organisation.
Imagine you simply want to change the question asked before an appointment. If this ordinary change requires three specialists and the deployment of several services, we should be able to explain what this complexity gives you in return.
A PWA can provide useful capabilities for a service consulted regularly: installation, certain offline functions, or notifications, depending on what is developed and supported. These are not automatic benefits obtained by sticking a label on the site.
If your customers return to their account area every day, the benefit is worth studying. If they come once to check your opening hours, a fast and clear mobile site might already meet the need. The question is usage, not the prestige of the acronym.
I would ask a provider to take an ordinary change in your business and describe how it would be implemented. Adding a service, changing a booking rule, retrieving data: this often leads to a more useful discussion than "which technology is the most powerful?".
We also need to talk about the exit. What will you be able to retrieve if the collaboration ends? Who will have access to the domain, the data, and the services? An architecture can be very elegant while making you dependent on a tool or a person.
At Cadarsir, I start with what the site needs to do, then I choose the blocks and the scope. A specialised technology can certainly be the right answer when it solves an identified problem. It doesn't need to be trendy for that.
Your business must be able to move forward thanks to the site. If the architecture becomes the main topic of every exchange while a simple request is still waiting, we've probably got our priorities backwards.
I'm not against new tools. A developer has the right to enjoy trying things out. The problem starts when their desire to experiment becomes your invoice, and then your maintenance headache for years to come.
A stack is the set of technical building blocks for a project. You can choose it well without chasing every new name, and choose it poorly even with well-known technologies. The starting point must remain what needs to be built.
You don't compare an engine, a boot, and a motorway
MongoDB is a database. NoSQL refers to a group of database families, including document-oriented ones like MongoDB. MySQL is a relational database. Next.js is a framework built around React for creating web applications; Symfony is a PHP framework. Varnish acts as an HTTP cache and reverse proxy. A PWA involves capabilities and an application-like experience provided by the web.These terms are therefore not competing answers to a single question. A project can combine several of these blocks. Saying "we're hesitating between MongoDB and a PWA" is a bit like hesitating between a car's boot and the way it drives.
You don't have to memorise the whole dictionary. Above all, your provider should be able to explain what responsibility each block fulfils, and what makes it necessary for your project.
Data doesn't become simple just because the database is flexible
Take an order: it belongs to a customer, contains products, has an amount, and can be linked to a payment. We must be able to find these relationships and enforce the rules that go with them.A relational database like MySQL lends itself to an organisation of linked tables. This is often a very readable way to represent this type of activity. With MongoDB, data is organised into documents, choosing what to group and what to reference. This approach can suit other forms of data and their uses.
It's not "rules" versus "no rules". MongoDB also allows working with relationships and transactions. Its documentation on modelling et transactions shows that the choice requires real design. Flexibility doesn't remove the need to know what you're recording, how you find it, and how you evolve it.
A product sheet that changes shape frequently might suggest studying a document model. A set of orders, invoices, and access rights can make a relational model very natural. These are avenues for thought, not rules that automatically designate a winner.
And "we will have a lot of data one day" is not yet a measure of load. Before preparing the site for millions of imaginary users, let's look at what will actually be required of it at launch.
A modern interface doesn't force you to multiply applications
Next.js can be used to build an interface and its rendering mechanisms around React. Symfony can carry a structured application, its business logic, forms, and integrations. Their exact role depends on the project; Next.js isn't limited to the browser, and Symfony doesn't forbid interactive interfaces.You can use one, the other, or make them work together. The documentation for Next.js et de Symfony presents their possibilities. None of them say your quote form needs two independent applications.
Separating an interface and a back-end can be very useful. But it can also add an API to manage, multiple deployments, access between services, and more testing. The benefit must justify this organisation.
Imagine you simply want to change the question asked before an appointment. If this ordinary change requires three specialists and the deployment of several services, we should be able to explain what this complexity gives you in return.
A cache or a PWA must solve something
Varnish can prevent the server from repeating the same work for responses that can be shared. This is interesting, but you also need to know when to refresh what's in the cache. Serving an old price very quickly is not the desired result. I explain the mechanism in the article dedicated to Varnish.A PWA can provide useful capabilities for a service consulted regularly: installation, certain offline functions, or notifications, depending on what is developed and supported. These are not automatic benefits obtained by sticking a label on the site.
If your customers return to their account area every day, the benefit is worth studying. If they come once to check your opening hours, a fast and clear mobile site might already meet the need. The question is usage, not the prestige of the acronym.
The quote doesn't yet show the next three years
The tools chosen influence what you will pay after delivery: hosting, external subscriptions, updates, monitoring, and evolutions. They also influence how easily another person can take over the work.I would ask a provider to take an ordinary change in your business and describe how it would be implemented. Adding a service, changing a booking rule, retrieving data: this often leads to a more useful discussion than "which technology is the most powerful?".
We also need to talk about the exit. What will you be able to retrieve if the collaboration ends? Who will have access to the domain, the data, and the services? An architecture can be very elegant while making you dependent on a tool or a person.
I prefer technology that we know how to keep alive
A proven foundation has concrete value: its behaviours are better known, and tools, documentation, and skills exist to operate it. This is no reason to reject all novelty. It is a reason not to treat novelty as sufficient proof.At Cadarsir, I start with what the site needs to do, then I choose the blocks and the scope. A specialised technology can certainly be the right answer when it solves an identified problem. It doesn't need to be trendy for that.
Your business must be able to move forward thanks to the site. If the architecture becomes the main topic of every exchange while a simple request is still waiting, we've probably got our priorities backwards.
