I am currently learning Spring boot for web development, but I am a little confused about how the web app should be structured. I am building a to do list web app, but I wanted to add some sort of user account system where each user has their own to do list. Hence, my idea was to use a One to many database relationship where I map a user to many tasks. However, after trying to implement this, I am not sure when the task layers would be needed since if any user wants to add a task, they would do so in the user layers. However, then it seems like there would never be a need for any other sets of layers if they all go through the User layers. What would be the proper way to implement the one-to-many mapping? Would it be to just have the User layers?
structure for my web app
Related
I want to keep track (with persistency) of users interactions with a microservice application developed with spring boot, so that i could consult them if something happened even maybe a year later.. One solution i found was use event sourcing and the problem was gone.. but due to some constraints i cannot go with that solution (in this project) so i was wondering..
Question
How can I track all user interactions and persist them in a spring boot microservice application?
if all the interactions that you want to track are sent to the server, then you can persist them in the database when the request is received in the server. To know who is the user you must need a way to identify him, for example, by using a token if the user is authenticated.
However, although this can be a solution the usual way to do this is using google analytics https://analytics.google.com/analytics/web/provision/#/provision
or snowplow https://snowplowanalytics.com/
Any of them track the actions done by the user in the frontend of the application
I have just developped a Human Ressource WebApp in Laravel.
So in this app, I have my user database.
Now, I have 2 old apps, that I'm about to rewrite / Migrate to Laravel.
The first one is to manage employee payments.
The second app is for monitoring my salesforce in field.
So, Basically, I will basically rewrite them.
My Question is about architecture. I will develop those 2 apps separating APIs in Lumen / Laravel for each app, individually, and then writing clients in Angular2.
I will use OAuth2.0 to set authorization and scopes between apps.
Now, My indecision resides on Database part.
Should I keep database separated, include database in the same schema, or how should I deal with my databases.
Today, I have 1 DB per app, but also, I have redundancy in users: Each App works with the same users, and so duplicate this info.
Right now, When User is created in App1, it calls APIs to create it in app2 and app3. This is not so nice, IMHO.
So, I think I would like to have a single User Database, but I don't really have experience of that:
should I extract User's info in a central database for all users, should
should I keep User's info duplicated between my DB?
if I keep it in 3 differents DB, how should I make JOINs, transactions, Foreign Keys, etc.
I know there is not 1 answer, it depends of what I want, but this is also my problem, I don't know which question should I be asking to make my decision???
It is important to mention that I don't have so much traffic, max 1000 users, and they all belongs to my enterprise, it will not increase to much. So, really, make a scallable app should not be my priority right now.
Any Advice will be appreciated!!!
Since you have shared databases between your apps, the common practice is to have it in the same Laravel/Lumen app.
The way you can achieve this is separating the apps inside route groups, namespacing the controllers hierarchies of each app and declaring inside each model the connection you will be using for this model.
This way you can use the same DB connections for all of your apps, and share the same data without the need of duplicating it.
I have a certain requirement where i will have a central laravel application, and it has all the users in there. Then there are 2-3 sub laravel applications. The users are individually given access to these sub applications.
Now the requirement is that these sub applications shouldn't have any users in there. They should query the central laravel application (through api).
So if someone signs in the central laravel application, it should automatically sign-in to the other applications that they are given access to.
I am aware that providing code wont be possible, so just an overall overview of how it might work and some packages that might be helpful would be really great. Thanks in advance.
I have pretty much done this. I really struggled to find examples/advice so just started building it.
I have several applications, all for internal use.
I have one application/db for storing users/roles/permissions.
In my other applications, the user model just points to the usermanager db.
When user log in, I grab all their permissions for this application and store them in the session.
Seems to be working so far.
Mick
We are upgrading a single-tenant application to a multi-tenant (separate DB for each client) SaaS application. My responsibility is to design the tenant provisioning part. I am thinking of the following steps.
While our admin will install our software, one DB should always be get created.Argument for this step is that Admin will install the software only when at least a tenant comes up. So, creation of a single db as part of installation of our software should make sense.
The common meta data will be stored in a common place. We are thinking of using ZooKeepar to store the common meta data.
Each tenant will be given a subdomain. For example www..samplaTenent.com . This tenant_id will be extracted from the URL in each request and will be used to identify the particular tenant and respective DB.
If more tenants need to be provisioned, the admin will create a new DB instance through user interface.
Technology used:
Java 6
Struts Framework
MS SQL
Now, I would like to get expert opinion about the proposed solutions. Is there any other way by which we can build a robust, secure and scale-able SaaS application?
Thanks.
IMHO, I would suggest that you should have a sibgle code base that can handle the multi-tenancy aspects be it configuration of db, settings per tenant etc.. I am not aware of the code base that you have now. Hence, you can make the provisioning part as follows,
You provision a new tenant by getting all the prerequisite info. You can generate the URL for this tenant automatically or allow the tenant to choose one in the latter a validation has to be made for the URL and the tenant combination.
On this step completion, you can have some scripts at the server that clones a master code base and rolls out a new tenant specific db. So things are automated.
The next step will be to store the tenant db and the app details in your common or shared db so that when a tenant logs in, you can redirect him to his URL. The db details will be required if you want to handle all of the tenant and his user authentication from the main app.
The main perceived advantage of having a single code base is that the customization and configuration can be in one place with ease of code maintenance and bug fixing or enhancing. Though this may not work for all scenarios, this is what I feel more suitable option on the long run.
Please share your thoughts or post additional queries that you may have on multi-tenancy.
I have a project which is a single solution in VS2010, and I wanted to have it such that:
Solution one: Admin
Solution Two: Front end
Solution three: Models
The reason for this is that Admin will sit in it's own app pool and the front end will sit in another app pool. We then have model talk to both and under model is the SQL database.
my question is:
How do I set this up in to three separate projects such that models can talk to Admin, Front end and the database?
For what you describe I think you'd be better off keeping one Solution and having multiple projects under it.
You can deploy the results of building the Admin project to one web site and the results of building the Front End project to another web site.
Each of these would reference the Models project. Models don't normally 'talk to' other projects but are referenced by them because the initiating action is coming from a web page request to either site - that's what's controlling the flow.
Often you'd also have another project which is a background service which may also reference your models project. This project would run as an NT Service providing time-based execution of work items that aren't tied to an incoming web request, for example, sending emails.
A further level of complexity would be to introduce a services layer and Data Transfer Objects (DTOs). You background service and all web sites now call into the services layer and interact only with DTOs while the service layer uses model objects to communicate with the database. You can now evolve your database schema independently from your web applications provided the service contract remains the same.