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

SharonG's avatar

Is Laravel suitable for this project?

Apologies that this is a really basic question, but I'm not sure where to ask - please redirect me if there's a more appropriate place.

I've been asked to build a web app, having not done so for a few years. Previously (5 years ago) I always used CakePHP to build the entire thing, including connecting to the database etc. It worked well for websites, but not for mobile apps. More recently I've been working with React and React Native, to make web and mobile apps, but in these projects I was working with other people who built the back end (using Springboot).

Now I've been asked to build a full-stack app; initially it will be a website, but there are plans to build apps in the future. CakePHP is probably not ideal, because it doesn't expand easily to mobile apps (as far as I know), and I don't know enough Java to set up a Springboot back end and use React. I also suspect technology has moved on since I started using CakePHP 15 years ago! On searching, I came across Laravel, and it looks like a reasonable option... I'm just not completely clear on what it does.

Could I use Laravel to build a sort of 'headless' CMS, so basically the back end, which connects to the database and manages the content etc, and then use React/React Native to create web/mobile apps which connect to that back end? I want users to be able to sign into the website/app, and pay for a subscription using Stripe. There should also be admins who can sign in to control the home page content (it's fine if regular users and admin users have to sign in in separate places.

Is this do-able with Laravel? Is this the kind of thing it's designed to do? Thanks!

0 likes
7 replies
martinbean's avatar

@sharong No need to apologise!

I actually moved to Laravel from CakePHP. I worked with CakePHP from versions 1 through 3 before making the switch to Laravel around 2013/2014.

Laravel, like CakePHP, is a full-stack framework written in PHP, so anything you would have been able to do with CakePHP you’ll be able to do with Laravel. You can use it to build web applications, APIs, or a project that is a mixture of both. So if you wanted to create a headless project that exposed an API only then you could do that with Laravel.

For the mobile apps, they’ll still be created with a different technology (Swift, Kotlin, Flutter, React Native, etc). But they could interact with a Laravel-built API to retrieve and persist data. You’ll also need some form of authentication. Laravel has first-party packages for this. There’s Passport which adds OAuth to your application. So you could create OAuth clients for your mobile applications, and then your mobile applications could use its endpoints to obtain an OAuth access token for authorising the user and API requests the app would make.

There is also Sanctum, which adds a more simpler method of token-based authentication; but unless you were also building a SPA (Single Page Application)—which is sounds like you’re not—I’d always err towards Passport with OAuth being an actual, standardised authorisation protocol.

The only thing I’d say to be wary of is that Apple doesn’t like apps that handle payments outside of its ecosystem. So you may find that you won’t be able to use Stripe in your iOS app. This isn’t a Laravel drawback; it’s just how the App Store on iOS operates. I’m not sure if Google operates a similar policy for Android apps.

2 likes
SharonG's avatar

Thanks martinbean, that's all great to know! In terms of Stripe, I've made apps (in React Native) before which used Stripe to accept payments, and never had any issues... can you tell me more about when those problems might happen?

martinbean's avatar

@SharonG Apple may have relaxed or even repealed the condition, but I know at one point that if you app required a subscription to function, then that subscription had to go through Apple’s payment services. It was what caused the rift between Apple and Epic Games a little while ago. Epic then sued Apple, but don‘t really know what the outcome of the case was and where Apple stands on payments today.

Apps like Netflix seem to skirt around it by saying they’re “reader” apps, i.e. their functionality is for consuming already-purchased content. I’m sure the guidelines will state what apps will need to exclusively use Apple’s payment services, If any.

1 like
SharonG's avatar

@martinbean Thanks. When I think about it, the website will be where the person pays; the apps will just allow them access to the content once they've subscribed.

litvinjuan's avatar

On authentication, I'd suggest going for sanctum all the way. OAuth is great when a 3rd party service needs to authenticate users within your app but not the right approach when you want to authenticate your users. Token based authentication has been a standard for years both in websites and mobile apps, so sanctum is the way. On everything else, I agree that Laravel will be great for what you're trying to do. Look at the laravel docs specifically for building an api. You'll find loads of tools specifically made for it.

martinbean's avatar

OAuth is great when a 3rd party service needs to authenticate users within your app but not the right approach when you want to authenticate your users.

@litvinjuan OAuth is literally for users to authorise access to their owned resources. The user is prompted to log in and by default is presented an authorisation screen saying something along the lines of “App X wants to use your account”. If the OAuth client is declared as a first-party client, then the authorisation screen is bypassed and all the user does is log in and is then redirected back to the app, where the app receives an OAuth token to make API requests as that user.

Token based authentication has been a standard for years both in websites and mobile apps, so sanctum is the way.

Indeed. And people were implementing and using token-based authentication for years before Sanctum came along.

1 like

Please or to participate in this conversation.