Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
First of all, I spent some time thinking whether this question belongs to SO, so if you think it is more appropriate for some other Stack Exchange site, please feel free to recommend or migrate.
I am writing a REST application which will be able to register new users and allow the existing users to interact with each other (you can imagine a forum or a minimalistic social network, for example).
At the moment, I have a simple app setup with database schema, spring-JPA and spring-data-rest exposing all the repositories.
However, all users are now able to access all the resources from the server. I would like a user to see only his own entities: for example by going to /api/user/messages.
I am also going to use some security in the application, probably OAuth2, so I need it to be compatible.
I have read some articles and SO questions concerning this topic and decided that multi-tenancy might be a solution to my problem. Usually though, these articles work with separate databases for each client and smaller number of clients in total so I am curious whether it is actually meant to be used for a huge number of users in the system. I expect all the users to share the database with their records and use the same schema.
Is there some tutorial for this topic concerning spring boot and shared database-schema? Or is there some better approach how to solve this problem? I would be glad for any tips!
EDIT: As pointed out in the comments, using multi-tenancy might be an overkill for this task, since I only need to separate the users on entity level. I would be glad for any hint how to do that in Spring boot and JPA since I have found no tutorials concerning this topic.
There aren't many explanations on how to achieve what you've described even though it would seem to be a common problem. Hopefully the Spring team will address this very common use case. The following is what I've seen as two possible solutions, the second of which is what I use.
Complex Solution:
Spring Security ACL
Simple Solution:
#Query Method Security Expressions
Example:
#Query("select m from Message m where m.user like ?#{hasRole('ADMIN') ? '%' : authentication.name}")
#Query methods are typically used to define more complex queries than can't easily be written in the method-name query creation that is a standard mechanism of Spring Data.
You can add Security logic within a #Query method that can return different results based on who the User is.
The above example will return all Messages if the User has a Role of ADMIN, but if not it will return only their own Messages. This has the added benefit of Query optimization. You could select all the records and then programmatically filter out those that the User doesn't have access to, but for large queries this becomes a bottleneck. This will adjust the query at runtime based on who is requesting the data. I've found it to be the best way to achieve the desired behavior without implementing a full ACL.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 1 year ago.
Improve this question
I'm sorry since I'm new to this.. I'm currently working on my startup which basically like food delivery system and I used Flutter for my app. I learned Flutter using Firebase as a backend. However, there are many sources that recommend use MongoDB as a backend database which I have zero knowledge about it. But I think that MongoDB just only offer for database crud operation. So I think for the database crud operation my app should use MongoDB. However, I think MongoDB is quite complicated when it involves authentication. So, which is better approach for me? should I use Firebase for authentication and MongoDB as the database or is it better to use only one platform for the backend whether its a Firebase or MongoDB? If I mix these two, does it will affect the pricing? Is there any ways that can make me clear which to choose.
MongoDB is an open source NoSQL database management program, which is quite useful for working with large sets of distributed data. It is mostly useful for big data applications and other processing jobs involving data that doesn't fit well in a rigid relational model.
It is an absolutely right approach to use Firebase Auth for just login or signup and the rest on MongoDB. There are 2 ways you can implement the Firebase Auth:
1. Using the SDK provided by Firebase
2. Using the Admin Auth API
You may select any of the above two approaches to save your UID on your custom Backend which might be MongoDB.
Contrarily, Firebase can also be used as backend. It provides the back-end server, a great database and analytics solution, and useful integrations with other Google products. Its free to use, affordable subscription options, wisely designed backend solution guarantees project scalability and data security makes it a great choice for backend.
However, for the vast majority of apps and use-cases, Firebase is an excellent choice. You can start with its free tier and don’t need to worry about maintenance or scalability. It’s great for small to medium developers as it allows them to lower initial costs while focusing on providing the best user experience.
When working on a heavy real-time app like chat, or some other highly collaborative experience, Firebase is still an option, though it might be a bit pricey.
However, the recommendation is always to consider your budget, the required feature set, and how much maintenance you’re willing to do on your own before making a decision.
You might also refer to this documentation, which will guide you with the pros and cons of choosing Firebase as backend.
Flutter: can I mix Firebase Auth with Mongodb Databases?
Check this similar post. If you still have doubts, feel free to ask.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm creating an application (web application) that needs to consume data (update client transactions) from a Kafka broker, but I'm not sure whats the best way to approach this.
I can think of three different scenarios to process each update:
Install the Kafka consumer directly in my app, then I can just start another instance of it (I'm using docker, so another container) and make the required updates there (I think this is the fastest one).
Create a separate service that consumes from Kafka and make the required updates in the app database. It seems to be pretty much the same as option 1, but a smaller app and more maintenance (2 apps instead of 1).
Create a separate service that consumes from Kafka and sends the updates to a REST endpoint in my app. It seems this would be a tiny service, very specific and the process remains in the app; but the app will receive more requests.
So, which are the pros/cons of each solution? Are all of them valid or some of them are a complete no? What drawbacks/risks should I be aware of?
I'm not looking just for a recommendation, I am more interested in understanding which solution works best for a given scenario.
Thank you.
With 3 you are splitting your application into multiple services. When you distribute your code across multiple services, you increase the level of indirection. The more indirection you have in your codebase, the harder it is for one person to work across the entire codebase because they have to keep more things in their head, and working across network boundaries requires a lot more code than working across files, and finally it's harder to debug across a network API.
Now, this doesn't mean that it's bad to split your application into multiple services. Doing so will help you scale your application as you can scale only the pieces that need scaling. Perhaps more importantly, splitting your application into multiple services makes it easier for more people to work on the codebase at the same time, since they have to adhere to the API contracts between the services, and are less likely to be working on the same files at the same time.
So 3 is a good choice if you have scaling issues, either for load on your application, or the number of developers that will work on it.
1 is a good choice if you want to move as quickly as possible and can put off scaling concerns for some time.
2 is the worst of both worlds. Your two services will be coupled by the database schema and will be sharing the same database instance. The separation of code means that you have extra indirection, the database schema coupling means that you won't fully get the people scaling benefits, and since most applications are bottlenecked by the database, the sharing of the db instance will deprive you of scaling independently for performance.
Personal rule-of-thumb -
If you have control of the REST API code, then the first one.
If the API has specific validation before reaching the database, dont do the second one unless you plan on copying that code into the consumer. If you want to write directly to a database, then Kafka Connect is the suggested framework for that, not a plain consumer, anyway
If you dont control the API code (its a third-party API), then you are left with option 3
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm working on a project with a requirement of coming up with a huge amount of data.
For this we are looking for a data store to save and fetch a huge amount of data. The database is easy, there is one object for vouchers and a one to many relation to transactions. One voucher has ~ 10 - 100 transaction.
Sometimes it is possible that the system has to generate several thousand voucher in a short time, and it also possible that the system writes or delete several thousand transaction.
And it is very important that the applications returns quickly if a voucher is valid or not (easy search request).
I have looked several blogs to find the best database for this and on the shortlist is
MongoDB
Elastic Search
Cassandra
My favourite is Elastic Search but I found several blogs which says ES is not reliable enough to use as a primary data store.
I also read some blogs that say mongodb has problems to run in cluster.
Do you have experience with Cassandra for a job like this? Or do you prefer any other database?
I've some experience on MongoDB, but I'll go agnostic on this.
There are MANY factors that goes in game when you say that you want a fast database. You have to think about indexing, vertical or horizontal scaling, relational or nosql, writing performance vs reading performance, and if you choose any of them should think about reading preferences, balancing, networking... The topics goes from the DB to the hardware.
I'd suggest go for a database you know, and that you can scale, admin and tune well.
In my personal experience, I've had no problems running MongoDB on cluster (sharding), may be problems comes due to a bad administration or planning, and that's why I suggest going for a database you know well.
The selection of the database is the least concern in designing a huge database that needs high performance. Most Nosql and Relational databases can be made to run this type of application effectively. The hardware is critical, the actual design of your database and your indexing is critical, the types of queries you run need to be performant.
If I were to take on a project that required a very large database with high performance, the first and most critical thing to do is to hire a database expert who has worked with those types of systems for several years. This is not something an application developer should EVER do. This is not the job for a beginner or even someone like me who has worked with only medium sized databases, albeit for over 20 years. You get what you pay for. In this case, you need to pay for real expertise at the design stage because database design mistakes are difficult to fix once they have data. Hire a contractor if you don't want a permanent emplyee, but hire expertise.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm tasked with investigating for our firm a full-stack solution where we'll be using a NoSQL database backend. It'll most likely be fed from a data warehouse and/or operational data store of some type in near-realtime (hopefully :). It will be used mainly by our mobile and web applications via REST.
A few requirements/assumptions:
It will be read-only (in the near term) and consumed by clients in REST format
It has to be scalable
Fast response time
Enterprise support - or if lacking actual support, something industry proven if open-source (basically management wants to hold
someone accountable if something in the stack fails)
Minimal client data transformations - i.e: data should be stored in as close to ready-to-use format as possible
Service API Management of some sort will most likely be needed (eg: 3scale)
Services will be used internally, but solution shouldn't prevent us from exposing them externally as a longterm goal
Micro-services are preferable (provided sufficient API management is in place)
We have in-house expertise in Java and Grails for our mobile/portal solutions
Some of the options I was tossing around were:
CouchDB: inherently returns REST - no need for translation layer - as
long as clients speak REST, we're all good
MongoDB: need a REST layer in between client and DB - haven't found a widely used one based on my investigation (the ones on Mongo's site all seem in their infancy - i.e: RestHeart)
Some questions I have:
Do I need an appserver? Or any layer in between the client and DB
for performance/caching reasons? I was thinking a reverse-proxy like
nginx would be a good idea for this?
Why not use CouchDB in this solution if it supports REST out of the box?
I'm struggling with deciding between which NoSQL DB to use, whether or not I need a REST translation layer, appserver, etc. I've read the pros and cons of each and mostly they say go Mongo - but for what I'm trying to do the lack of a mature REST layer is concerning.
I'm just looking for some ideas, tips, lessons learned that anyone out there would be willing to share.
Thanks!
The problem with exposing the database directly to the client is that most databases do not support permission control which is as fine-grained as you want it to be. You often can not allow a client to view and edit its own data while also forbidding it from viewing and editing any data of other users or even worse from the server itself. At least not when you still want a sane database schema.
You will also often find yourself in the situation that you have a document with several fields of which only some are supposed to be under the control of the user and others are not. I can, for example, edit the content of this answer, but I can not edit the time it was posted, the name it was posted under or its voting score. So far I have never seen a database system which can handle permission for individual fields (when anyone has: feel free to post in the comments).
You might think about trying to handle this on the client and just don't offer any user interface for editing said fields. But that will only work in a trusted environment. When you have untrusted users, they could create a clone of your client-sided application which does expose this functionality. There is no way for you to tell the difference between the genuine client and a clone, especially not when you don't have a smart application server (and even then it is practically impossible).
For that reason it is almost always required to have an application server between clients and database which handles authentication and permission management of the clients and only forwards those requests to the persistence layer which are permitted.
I totally agree with the answer from #Philipp. In the case of using CouchDB you will minimum want to use a proxy server in front to enable SSL.
Almost all of your requirements can be fulfilled by CouchDB. Especially the upcoming v2 will give you the "datacenter-needs".
But it's simply very complex to answer what should be the right tool for you purpose. If you get some business model requirements on top like lets say: throttling - then you will definitely need an application server middleware like http://mcavage.me/node-restify/
Maybe it's a good idea to spend some money to professionals like
http://www.neighbourhood.ie/couchdb-support/ ? (I'm not involved)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I am looking to revamp our CRUD web forms and would appreciate any examples of good UI design.
We have lots of database tables that have minimal editing needs by the user - Country Codes, Tax codes, Product prices, and so on - and these all currently use a simple format for CRUD, but it was designed by developers and looks very bland, and quite possibly could have far better usability, and certainly a better design.
Our process is:
Find screen - which also has an ADD NEW button. Enter values for any parameters relevant to search for and press FIND button. Matching records displayed in a grid with an EDIT link. The corresponding Edit form allows CLONE, DELETE and SAVE.
Where appropriate an Edit form may display Child Records.
For very complex records / relationships the Edit form is replaced by a Record Card, which displays everything including the kitchen sink! and appropriate records / sub records have EDIT links.
Its functional, but uninspiring.
On an 80:20 basis the code is all mechanically generated, so re-generating it for a new metaphor shouldn't be too hard.
I like a lot of the UI in the Magento eCommerce Admin pages, but I would be interested in any other examples you can recommend
Here are some examples of UI patterns:
Input Controls
Stacked Tabs
Inline Input Adder
One Page Wizards
Overlay
Generally each section will explain the pattern, how and why to use, and gives a handful of graphics as real world examples.
As an additional resource, you can also visit ThemeForest's admin template site and browse through their many products and get pictures and live tours of very well designed and styled admin pages. I personally have used a few of these templates for data heavy sites.
Hope these help you out some.
7/25/18 Update: While it is hard to keep links from nine years ago working, it seem that the website which hosted the UI examples is now gone. Read Farewell from Patternry for further information.
Links worth a look:
http://www.smashingmagazine.com/2008/04/17/web-form-design-modern-solutions-and-creative-ideas/
http://somerandomdude.com/articles/design/form-design/
The Dynamic Data Web Site that you can create using .Net 3.5 is pretty handy. Good clean dynamic CRUD ability and yet very customizable. Routing makes it possible to default to generated pages when needed and custom pages if you choose to create them.
Dynamic Data Web Site
These guys have really nice examples-
http://wufoo.com/gallery/
To me, the Django admin interface is a good example of a CRUD interface.
I've just stumbled onto this one
there you will find a couple of REALLY GREAT templates!!!
http://www.webappers.com/2009/09/18/20-professional-web-admin-templates-on-themeforest/