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

Rretzko's avatar
Level 15

Best design option for two-sided engagement

Hi folks - I’d appreciate your thoughts on the best way to architect this: I have an application that manages audition event registration with three audiences:teachers, students, and event administration. Currently, the students sign in through one portal with a unique domain and the teachers and event administrators (who are also teachers) sign in through a separate address both use the same database. Due to students being students, I want to keep them as isolated from the teachers work as possible. This, of course, results in significant duplication of code as the student functionality is a subset but not identical to the teacher functionality. What are your recommendations on how this should be designed: a) continue with the separate apps and accept the duplication, b) set up an api that handles both apps needs, or c) something else? Thanks for your time and thoughts! Rick

0 likes
3 replies
LaryAI's avatar
Level 58

Hi Rick,

Your scenario is a common one in web application design where you have different user roles with overlapping but distinct functionalities. Here are some thoughts on how you can architect this more efficiently:

Option A: Continue with Separate Apps

This option is the simplest but leads to code duplication and maintenance challenges. It might be acceptable if the overlap is minimal and the applications are small, but it doesn't scale well.

Option B: Set Up an API

Creating a shared API that both the student and teacher portals can interact with is a more scalable and maintainable solution. This way, you can centralize your business logic and data access, reducing duplication. Each portal can then be a thin client that focuses on the user interface and user experience.

Option C: Single Application with Role-Based Access Control

Another approach is to have a single application with role-based access control (RBAC). This way, you can serve different views and functionalities based on the user's role. This can be achieved using middleware to check user roles and permissions.

Recommended Solution: API with Role-Based Access Control

Combining Option B and Option C might give you the best of both worlds. Here's a high-level approach:

  1. Create a Shared API: Develop a RESTful API that handles all the business logic and data access. This API will serve both the student and teacher portals.

  2. Role-Based Access Control: Implement RBAC in your API and front-end applications. This ensures that students, teachers, and administrators only have access to the functionalities they are permitted to use.

  3. Separate Front-End Applications: Maintain separate front-end applications for students and teachers if the user interfaces are significantly different. These front-ends will consume the shared API.

Example Code

API (Node.js/Express)

const express = require('express');
const app = express();
const port = 3000;

// Middleware for role-based access control
function checkRole(role) {
  return (req, res, next) => {
    if (req.user && req.user.role === role) {
      next();
    } else {
      res.status(403).send('Forbidden');
    }
  };
}

// Example route for students
app.get('/student/data', checkRole('student'), (req, res) => {
  res.send('Student data');
});

// Example route for teachers
app.get('/teacher/data', checkRole('teacher'), (req, res) => {
  res.send('Teacher data');
});

app.listen(port, () => {
  console.log(`API listening at http://localhost:${port}`);
});

Front-End (React)

Conclusion

By creating a shared API and implementing role-based access control, you can reduce code duplication and make your application more maintainable. Separate front-end applications can still be used to cater to different user experiences while consuming the same API.

I hope this helps! Let me know if you have any further questions.

Best, LaracastsGPT

Rretzko's avatar
Level 15

@MohamedTammam: Thanks for the reply and thoughts and I don't disagree. Unfortunately, my branding for each site is role-specific and I'm not eager to engage in a rebranding effort at this time but looking for an optimal technical solution to handle the two sites.

Please or to participate in this conversation.