Tag Info

New answers tagged

0

Got a response. I was looking for some kind of "Request/Respond" pattern implementation, that I found.


5

Unless User must have a Service to do user things, do not make the user pretend to be the application context/ overall state. "Convenience" and "LOC per class" are not design principles. Focus your classes sharply. Fanatically adhere to single responsibility principle. the user won't get that big Irrelevant. it'll probably end up being about ...


4

I would go with the Service.GetMeetings(user u) approach. Here's my reasoning. In my experience the only difference between these two approaches once you add DTOs and hosting projects for your services is naming. If you keep the logic out of User, then User is equivalent to your what your UserDTO would have been Your new Service Class seems like an extra ...


3

Each service should be self-contained. Most devs know that when something is "set in stone", it will change on you when you least expect it, forcing you to re-architect your solution. You should always design your solutions to be correct from a technological stance even if it makes things a little more complicated in the beginning. Separation of concerns ...


0

You can try to limit size and number of files the user can send to your API and use an strategy to identify the application (or device) when you receiving the request something like a key in the request header (for example 'Authentication: key '). This way you difficult people to use a REST client to post many files.


2

If your data is only meant to be persisted in Amazon S3 it's not performant to proxy it through your web server and should be avoided if possible. What you can do is create a POST policy that contains constraints on what the uploader (your Android app can do). You might create the following policy: Can only upload to specific bucket Specify min/max size ...


1

Is it necessary/sound to add the token to a database or can I just use the payload to identify the user? I think both approaches are fine. I've implemented token based authentication in .Net, and we put all identity related information in the token. I would argue it's more scalable, especially for a web farm. All the authentication information we need ...


0

Your token should contain the users id and a hash. If the hash matches the JWT, you're fine (as long as nobody knows the private key your are using to create that hash).


0

Is your work flow queue based? In other words, is your data transient in nature, do you need to support sub/sub, do you need to ensure only one client can poll the data etc. If it is, then using a queue system instead of a RDBMS makes sense by itself. That should be the deciding factor here. As for the more general question: No, I don't see why that would ...


5

Technically, such checking requires an additional step. You have to list all the parameters, and compare this list with the list of allowed ones. Then, if you decide to accept an additional parameter, you have to change this list, requiring even more work. All this code has to be tested as well. What's the benefit? The benefit is that a programmer who made ...



Top 50 recent answers are included