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 5 years ago.
Improve this question
I am studying the current architecture of uber rider app and I got to know the current rider app was evolved from MVC to a specific architecture called riblet, which is designed on top of viper by Uber themselves. As I understood riblets is independently testable pieces that each have a single purpose. I'm aware that the new architecture is capable of handling performance and scalability. I am interested in knowing the cons of riblet architecture.
Okey. I found some cons of the riblet architecture. I will post them here to discuss with anyone who is interested. The main cons are as follows,
Since there is a higher number of independent riblets communicating through their interfaces, there is a probability of failure of a particular interface compared to a system with fewer components.
Yes testing a single riblet is easy yet it makes integrations and handling the requests among riblets more complicated.
Changing the technology stack in the long run is difficult
Related
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 4 years ago.
Improve this question
I want to go with Xamarin.Forms project. Now, I am bit confuse for consuming Rest API for this project. Performance matters.
There are many available but can any body please suggest me which should be best for Xamarin.Forms(.Net Standard)?
Microsoft Http Libraries or third party libraries like Refit, RESTSharp, PortableRest, etc.
Please suggest
All of these options are viable. I think the performance differences between these libraries will be marginal. So, it mostly comes down to what you feel comfortable with.
I like to use Refit because it will take a lot of redundant code out of your hands and you just have to focus on the contract. All the code for the actual calls is generated at compile-time (and thus won't impact your performance at runtime).
Also have a look at how well the library is maintained and if it's active. If you choose one that is already inactive for a while, chances are that you will start relying on older software versions which might not be what you want.
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
Assume I have separated my monolithic application into 5 microservices.
Now do I need to run these 5 microservices in 5 processes or is it OK to have all 5 of them run in a single process? Why?
The very purpose of choosing to go with Microservice Architecture is to achieve scalability and agility through independence of services. Here is an excerpt from a good article on the matter, you might find interesting. It is by a pretty credible source - SmartBear (the creators of SOAPUI):
While there is no standard, formal definition of microservices, there
are certain characteristics that help us identify the style.
Essentially, microservice architecture is a method of developing
software applications as a suite of independently deployable, small,
modular services in which each service runs a unique process and
communicates through a well-defined, lightweight mechanism to serve a
business goal.
So yes, you should absolutely go for deployment as separate processes. You will be much more flexible this way. For example, running all 5 services in a single process could make it impossible to hot-swap new versions of single microservices without stopping all the others (even though they might not be logical interdependence between all services).
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
Did someone try developing a GraphQL instead of RESTful API? Can someone give real life (not only theoretical) pros and cons. Basically from my research I found that the GraphQL power is to get exactly what you need nothing more. Where with REST APIs, you often have to make a series of requests and you can easily get back more information than you really needed.
Is it worth the time spent on researching and learning GraphQL? Any bugs or showstoppers that get your attention?
This question is primarily opinion-based.
But from my experience:
Multiple requests on a RESTful-API for just one thing often indicates a lack in the API design, namely the needed resource was not available and therefore stuff needs to be gathered from different resources to compensate for this.
A REST-API that could be easily replaced by GraphQL indicates, that the API was in fact a CRUD-HTTP-API, what is considered an Anti-Pattern among REST-Evangelists.
Also worth noting is, that GraphQL puts responsibilty on the client, because the backing API is reduced to be a datastore that just needs to be queried. REST on the other hand enforces the behaviour of the client and therefore reduces responsibility on it. The client gets reduced to be something similar to a browser.
There are cases the one or the other approach would yield better results, but that greatly depends on your situation.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I've seen plenty of posts on the pros and cons of the EF but finding quite hard to find anything on the relationship between EF and project management methodologies such as Waterfall SDLC and Agile?
Would anyone have any links or information on the above? Thanks.
Frameworks and methodologies are typically orthogonal.
The only (indirect) relationship is that Agile methods would have you build your application to be decoupled from the persistence mechanism altogether. In fact, you would delay even using a database until you have a user story that requires that you have one. This would force you to keep the two decoupled, leaving your options open.
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 9 years ago.
Improve this question
I am starting to learn how to build rest Web service (I come from soap web service).
I'm an intermediate scala programer. I'd like to know as of now, what is the most widespread framework for building Restful Service. But i would also appreciate personal opinion on what is the easiest to use for the task of solely building rest api/web-service, very fast, with a not so complicate learning curve.
Many thanks,
-M-
Play, Scalatra and Spray are all good choices with a reasonable learning curve.
You'll have to look at these (and others), then decide which fits best with your own preferences. It's a very subjective question and there are too many variables for anyone to be able to give a definitive answer.