Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

cmdobueno's avatar

Web VS API on a project

So, I have an upcoming project and I have to figure out what my best course of action is moving forward, and this is something that I am sure will have a lot of opinions one way or another. So first off, I am just interested in opinions, and no one persons is better or worse than anybody else. All I ask is that you provide so information on why you would go down 1 path or another.

So what will this project do?

1. General HR system
    a. time cards
    b. pay stubs
    c. time off
    d. time off requests
2. Company Documents
    a. searchable
    b. revisions
    c. note: these are PDF's, excel files, and those type of items, they will not always be filled out on this system.
3. Scheduling (this is company has a 'factory' and there are production schedules)
    a. Auto-generate a schedule
    b. Approve auto-generated schedules
    c. Modify auto-generated schedules
    d. Tie into existing system via api (or that system can sometimes push data to this system). (All end points and required functionality exists on this 'other' system, and we have the ability to change things as required there)
4. There is more, and more, and more, but these are kind of the basics

This system will also be responsible for display information such as tasks, and the above noted schedules on things like read boards places through the facilities, so that everybody in the company basically always knows what each department (and sometimes person) is currently working on.

This is a system that will be accessible via the web, both internally and externally. I plan to use Laravel for the code of the system, and I am considering using Vue.js as the 'frontend'. This seems about started, of course I could use just blades, and all that but I do not really want to go down that path as I am about to describe.

I am considering building this specifically as an API. I know Vue.js (and other js frameworks eg angular) work will with apis' using things like axios. I want to get some additional feedback and real world experiences of people in this situation. Additionally this system is going to have to have native apps built for it (later down the line).

So the final question:

Is it best, based upon the above information, to build this system strictly as an API instead of a, for lack of a better term, 'web-site'?

I lean towards yes, with the understanding that parts of the system require an api to exist regardless of my choices. Building as simply an API would not require me to do work twice. Additionally it should ease the transition, should it ever occur to switch the frontend, or update apps. The API is effectively a stand along entity from the frontend.

Thanks for your response

0 likes
8 replies
jlrdw's avatar

Take a field trip:

  • visit a big bank
  • visit a large trucking company
  • visit other industries
  • visit a large hospital's record and billing section

Okay for business, what are they using?

For a single company like (General HR system) I would go with a normal web app, but keep mobile friendly in mind. An employee may want to view their work schedule on a mobile phone, thus you need responsive design (mobile friendly).

But I am sure that the billing needs to be entered on a regular desktop computer. I can't see a large hospital's billing entering data all day on their phones. No they use their work stations, as does the bank, etc.

Otherwise you made need two apps, but that's up to you.

Depending on need and size you may be forced into writing two apps, business side and a mobile app for some of the things. But good luck.

1 like
ohffs's avatar

I'm in the process (well, just started on it really) re-writing an old app and as I know in advance it will be consumed by other apps too (data sharing, some so I can lock down access etc) I've started going 'api first'. That way I'm dog-fooding my API as I build out the main 'meat and potatoes' part.

Usually I do 'web app first' with a bit of an API - but it can get a bit soul-destroying duplicating the work when you get another window onto the data from another app (sometimes it's even adding two separate API endpoints for the same thing as I'm a bit fast'n'loose with the internal one but the external needs to be a bit more locked down).

It's quite annoying in any case ;-) Loosing access to a lot of the nice comforts of a regular web application is quite frustrating :-/

cmdobueno's avatar

@ohffs

makes sense, see I am trying to avoid exactly what you are doing.

@jlrdw

I see your reasoning, more things I must consider going forward

There is so much to consider as I progress to getting this monster started.

jlrdw's avatar

Yeah sometimes it's hard to please everybody but you have to start somewhere.

But if it's for a business I would get the business side done first they will want to sit there enter data such as billing or whatever is needed.

Rember normally it's usually what's done on the desktop that's the main grind or biggest part of business. The mobile API apps are usually the frill parts for end users.

An example mobile banking app.

primordial's avatar
primordial
7 years ago
Best Answer
Level 7

Build an API(s) with a decoupled front end and consider breaking the back end into smaller chunks so you do not end up with one massive monolithic solution.

That would be my approach but I admit it's a big learning curve. In an ideal world; Token based authentication (passport) and numerous Docker containers inside a Kubernetes cluster.

Good luck.

cmdobueno's avatar

As a small update, I have been very large amounts of success build this as two systems. An API that my decoupled frontend connects to is working fantastic.

I am using JWT tokens for authentication, and just a very basic vuetify frontend for the 'portal' side of the system as I am calling it.

Dealing with a strictly API is making testing the core functions work perfectly and exactly how I had expected. Additionally it is very very fast to build out a test, and configure the system to simply work. Not having to worry about the display side of a frontend to do end point testing has really helped me in terms of speed an consistency in the code.

It was a bit slow starting out, and getting used too doing things that way, but as I progressed it just 'felt' right.

I want to thank everybody for their help and replied here. I may do another update later as I get into the meat and potatoes of the system. Currently I have just simply built out the authentication and security of the system. (I had coded it all instead of using packages simply to get used to how to follow the flow of this somewhat new process).

Again thanks all.

1 like
primordial's avatar

Well done, glad to hear it.

Taking your possible solution to the next level and and to elaborate on my earlier response; If I were building your solution(s) there would be a minimum of 7 docker containers/discrete developments.

DOCKER CONTAINERS

#1 Nginx that authorises all requests with your oAuth server before forwarding the request on

#2 OAuth server

#3 Front end (EG: Vue/Angular)

#5 HR System

#6 Company Documents

#7 Scheduling

Making use of queues (EG: AWS SQS or RabbitMQ) for event driven communication.

Anyway, just one possible approach. Rome was not built in a day and there are many different possibilities. But decoupling the front from the back is an excellent start.

Best of luck with your learning curve/project.

Please or to participate in this conversation.