0

I got a project assigned where we already have an up and running website and one of our clients wants to be able to track statistics from the website. We want to make this available to all our clients as soon as we finish the development. Note that each 'client' have their own 'subdomain' to say so. Eg. www.website.com/client1 , www.website.com/client2 , etc. And we want to track the usage separately for each of these clients.

We will need to create statistics based on the usage of our own platform, pull in data registered by Google Analytics and also pull in data from a 3rd party which they will offer by an API of their own (they have a 3rd party solution that uses the data accessible via our API). All this data needs to be shown on a webpage with graphs and tables.

I wanted to make sure we choose the right architecture from the start, in order to avoid scalability issues later on.

Started reading about Private and Public API's lately.

For now, we do not have another (internal) application yet that would use our own statisics, it would just be the website using it. But in order to be able to scale-up later if needed, and another application would like to use the statistics I think a private API would benefit us greatly.

In order to allow 3rd parties to use the statistical data we chose to let out, I was thinking of creating a Public API.

Is a Private&Public API the correct way to go about this?

One of the questions I am stuck with is how does the architecture for these API's look like. Mostly, right now we already have a public API regarding vacancy data. This 'API' is basically just a PHP class (controller) inside our CodeIgniter solution. It gets called via its URL and returns a JSON object with the results. (e.g. www.website.com/api/vacancy/xxx)

In order to create a (proper) private & public API solution/architecture. Should the API be set free from the website (CodeIgniter)? What are the common go-to solutions for this? Or is it fine to keep it in our current platform the way it is now? (and people call the stats API via www.website.com/api/stats/xxx for example?)

Stefan Zobel
  • 3,182
  • 7
  • 28
  • 38
Dennis
  • 3,044
  • 2
  • 33
  • 52

2 Answers2

1

It's almost always right to go with microservices like architecture so your initial thoughts sounds reasonable. Acting like this will give the possibility to scale and deploy your api independently and also will help you avoid performance side effects to your site (and vice versa). Pay attention how you access your main site data from within the new api if you don't want to finish with a monolith application. Regarding the API i would suggest you to implement protocol like oauth2 in order to achieve the flexibility you (might) need. Also you can use swagger to document and test your API. All i said might helps you a lot but first you have to answer yourself do you really need to go so deep or you just need a simple solution.

Plamen Paskov
  • 144
  • 3
  • 10
  • Thank you for the suggestions!! I will look further into it. As you mentioned to pay attention to how i access my site's data from within the API. What do you mean exactly? – Dennis Jan 27 '19 at 15:01
  • 2
    Long story short: you must avoid accessing the same db tables from multiple microservices because you tightly couple the services and update to the table will force updates to every microservice which use the table. You can check the discussion here: https://stackoverflow.com/questions/43612866/microservices-with-shared-database-using-multiple-orms/43618284 Of course you might violate the rules but be prepared to loose some flexibility – Plamen Paskov Jan 27 '19 at 15:48
1

I think multitenancy is the best choice. Generally speaking, multitenancy is when every customer has own database. Data is separate. The codebase is same and already exists. As I understood the project is in progress status. You do not redesign and rewrite anything.

Dmitresky
  • 536
  • 8
  • 21