How to structure your web/mobile app (part 1): URLs

If I ask why do we use URLs for, the straightforward answer would be that URLs are how you reach certain parts of a website, either by clicking on a link or by typing it in the browser URL bar. If you are more savvy, you could say it’s to locate a resource. That’s correct, but there is more to URLs than just website navigation. You can start organising the codebase itself around URLs. And, URLs are not just for websites, but for mobile apps too.

Let’s examine this in the context of SPA and mobile apps.

URLs for organising project files

URLs are entry points to your application. You are expected to return some kind of response when a request is made at a specific URL. Let’s just keep the folder structure in sync with the URL structure. Here is how it can look for an e-commerce website.

src/
---- pages/
-------- index.js
-------- categories/
------------ index.js
-------- products/
------------ index.js
-------- products/details/
----------------- index.js

When you visit https://myapp.com , your router points to src/pages/index.js where you may render the home screen. When you tap on a link on https://myapp.com/products, you will be taken to https://myapp.com/products/details?id=15 which corresponds to src/pages/products/details/index.js. The implementation of the router or anything else is not in the scope of this post. You can also have slightly different conventions here. But the gist is that the path in URL should be same as the path to the component which handles that URL.

If you have used Next or Nuxt, you are already familiar with this approach. What you might not be familiar with is the fact that same approach can be used in mobile apps as well.

URLs for mobile apps

Each screen in an app is equivalent to a web page. It’s a very good idea to assign a URL for each screen. Same structure posted above can be used in a react native application as well. This is useful for:

• Deep links: You don’t have to figure out a new way of mapping deep link values with screens. Deep links are URLs, so the routing convention is already setup!
• Analytics: The URLs uniquely identify the screens, which can be used to identify the events with a specific screen
• Namespacing: There is a direct mapping between folder structure and URL paths. This unification removes the need for unnecessary decision making towards where to put the code that handles a specific screen

A good URL structure

There has already been a lot of discussion about the URL structure. In general, keep the URLs resourceful . There is no point reinventing it. Borrowing from Ruby on Rails, Laravel, AdonisJS and such, here’s how I usually structure the URLs:

{collection-name}/{operation-name}

I am not a fan of path params though, especially in mobile apps. Keep it at one level, and accept whatever query parameters you need. /products/details?id=1000 is a lot simpler than/categories/15/products/1000. Your routing becomes much simpler. In a website, there may be SEO concerns which favour the path params. I will go with path params in such cases.

In conclusion, keep the project files organised based on the URLs, and organise your URLs based on the app features in a resourceful way. Here’s a talk by Adam Wathan which can help you in structuring those URLs in a nice way. While the talk itself is mostly in the context of a Laravel application, the approach is applicable for any URL.