Hi Emilien! Yeah, happily! Firstly, just want to point out that using either actions or services are perfectly acceptable options for the project we're building here. They're very similar, the primary difference being services are comprised of one class with many methods whereas with actions the service class is typically a folder and the methods are individual classes inside that folder for each action. So, actions just kind of scoot everything up a level.

With actions, since a class is dedicated to a single action, this means it is easier to split out sub actions, keeping things organized and easier to read by giving those sub actions names. I can't recall whether we've done this yet at this point in the series, but we most certainly do down the road!

Those separate classes also aide our ability to inject the HttpContext for specific actions. With services, that becomes a little more complicated and often leads to needing two different service classes (one with & one without the HttpContext injected). Whereas, with actions, we can easily make that determination on a per-action basis, which we do in this module (module 6) of the series.

Those two points are the primary deciding factors that lead me to use actions over services for this project. Actions may use more files, but that also brings with it more flexibility in how we write, organize, and inject things inside the project.

That wasn't a foresight thing either, I actually originally started this project with services (shown below) before switching to actions. Once I got to a certain level, I began feeling like actions would be the cleaner and less confusing way to go as opposed to having service methods daisy chaining other service methods to perform an action.

Hope that answers your question! 😊

Yeah, if I'm following correctly, you could probably achieve that with nested whereHas calls. This builds out WHERE EXISTS SQL clauses to query based on a relationship's existence.

const user = auth.use('web').user!
const organization = await Organization
  .query()
  .whereHas('users', (users) => users
    .where('users.id', user.id)
    .whereHas('setting', (setting => setting
      .where('name', 'default organization')
      .whereRaw('settings_id = organizations.id') // use db names in whereRaw
    )
  )
  .first()

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

If I'm thinking about this correctly, this would query the first organization where the id matches that of the authenticated user's user_settings.settings_id and the matched user_settings.name is also default organization.

Alternatively, you could query for the user_settings id first, then use that to query the organization.

let organization: Organization
const user = auth.use('web').user!
const defaultOrganization = await user
  .related('setting')
  .query()
  .where('name', 'default organization')
  .select('settingsId')
  .first()

if (defaultOrganization) {
  organization = await user
    .related('organizations')
    .query()
    .where('id', defaultOrganization.settingsId)
    .first()
}

  

    

      Copied!
      

        

      
    
  
  
    
    
    
    
    
  

Hi Nicolas! Thank you so much for your kind words!

Funny enough, we'll be following this series up by adding an API to it. It'll be a quicker series than this one, and we won't be adding all the features via API, but we'll structure it as though we were.

I personally would stick to actions, services would be a like alternative, because it provides a single location for our operations to live. It allows us to minimize operational duplication between the web & API layers, which in turn simplifies any refactoring needs down the road.

As for the routes, with this application in mind, yes I would duplicate those so that we have a route definition specific to the web & API layer. For the web layer, it is unlikely to ever need to do versioning as everything can be updated at the same time. The API layer, however, would likely need versioning so we don't randomly break the clients using the API with changes, with the assumption they won't be updated along with the API itself. Additionally, the middleware between these two are likely to be different and our API layer may need to be more complex with filtering and the like. Because of those things, I would also have separate controllers for the API layer as well.

However, if none of the above are issues for an API you're building then you don't need to do that. You can instead use a single route definition for both with a single controller that uses content negotiation to determine whether the client needs an API or a Web/Inertia response. You can always separate the routes/controllers between the web and API down the road. The approach there will vary depending on the project your building and its requirements.

Hope this helps!