Are both LoopBack and Breeze.JS to do the same to persist the data from the Node.JS client applications to database like MSSQL, Oracle etc...?
LoopBack is an exciting company with smart people.
I don't know much about LoopBack's data management offerings and, as one of the principals behind breeze, I don't feel comfortable making comparisons anyway.
I do think it's wise to consider every technology choice in the context of your broad business and application needs.
Let me suggest some areas to investigate:
What database(s) do you care about? How does the product actually work with those databases?
Do you need/want support on the server for
transactions
validation during save
batch save requests (mix of entity types and insert/update/delete)
batch query requests
Do you need/want support on the client for
client-side caching and events
tracking entity change state
property change notification
property and entity validation
automated entity graphs (e.g. just-in-time population and maintenance of entity navigation properties)
typed representation of sub-documents ("complex types")
original value tracking (ability to cancel pending changes)
serialization of entity graphs with circular references.
Will you need to consider integration with non-Node client or server technologies? With legacy applications and services?
Is there both developer and API documentation? How much? Does it provide the kind and quality of guidance you'll need?
How many questions have been asked on StackOverflow? What questions are people asking about the technology on StackOverflow? Are they the kinds of questions you'll be asking as you build your app? What do you think of the answers?
What do you require of customer support for the specific technologies you seek?
How established and stable is the technology you seek? Is the vendor well-versed in the issues and concerns of someone trying to solve these problems? Does this matter to you?
What are people actually doing with this technology? Look beyond the customer list. Find out whether these customers are doing what you want to do.
What is the vendor's experience designing and supporting the kinds of applications you intend to build with its technology?
Related
First and foremost, this post doesn't have any intention to strike down any parties as mentioned in my question.
In fact, I'm not sure whether i should ask this question to this forum or not, but after some thoughtful considerations i decided to just post it here due to my curiosity.
Shortly speaking, I'm working on IAM platform for one of my customer. I've prepared it using keycloak within a day which also cover custom provider to connect with their legacy user internal database.
But I got a pretty shock statement from my customer that they don't trust keycloak since it's free and open source. They only trust commercial products, and they suggested me to go with either forgerock or okta.
I have my own way to answer that statement, but I would also like to hear some feedbacks from the experts here with regards to that matter. Thanks in advance.
Maybe the customer concern is that there is no commercial support with Keycloak. It's a very practical concern, eg if you are not available at some future time and all apps are broken when something strange happens after upgrading the Authorization Server.
Of course on the technical side of things, keep code portable by implementing standards based solutions, so that you can switch providers. Avoid stuff like Keycloak Adapters if they are vendor specific.
DEPLOYMENT
As a containerized solution, Keycloak's deployment model supports multi cloud and means you can run in any cloud provider.
Then again, the Platform as a Service model of some providers is often attractive - no infra to manage and the hope of high availability. With some PAAS providers the trade off may be that there is less control over behavior.
WHAT ARE THE REAL REQUIREMENTS?
Commercial support
Guidance on app scenarios
High Availability
Ease of management
Extensibility
Portability
Different customers have different viewpoints and there is no right answer. The usual thing that software architects do is understand their audience, make recommendations, but let the customer decide - they are the boss after all.
After posting a question earlier, I started to wonder if an Entity Framework model (connecting to multiple databases) could run in a web garden with multiple worker processes? Has anyone attempted this?
Absolutely it can, due to EF's Unit of Work pattern it can work remarkably well in a web garden, it's not the ORM itself though that is a significant factor, it's the style and structure of the business logic that will make the difference.
One might even go so far as to say that EF is better suited for this than some other frameworks, but that is highly subjective, so we wont go there...
Unit of Work patterns work really well for REST style or stateless service implementations, if the state is not persisted between requests or across sessions then it is really easy to scale out the service implementation regardless of the framework that you are using to access the database.
That's not to say that a repository pattern can't be effective across a distributed hosting environment, personally I just find that with EF there is less boilerplate code and less effort to get the job done.
EF had a slow start, but it has matured into a very stable product, EF.Core looks to be heading in the right direction too ;)
The community of developers using odata for their REST implementations seem to be the least of all the REST implementations that I usually come across.
Any reasons?
There is virtually no contract. A service consumer has no idea how to use the service (for example, what are valid Command arguments, encoding expectations, and so on).
The interface errs on the side of being too liberal in what it will accept.
The contract does not provide enough information to consumers on how to use the service. If a consumer must read something other than the service’s signature to understand how to use the service, the factoring of the service should be reviewed.
Consumers are expected to be familiar with the database and table structures prior to consuming the Web service. This results in a tight coupling between service providers and consumers.
Performance will suffer due to dependencies on late binding and encoding/decoding between boundaries within the same service.
Source: https://docs.servicestack.net/why-not-odata
OData is a great standard to expose datasets with good tool support (Excel, Tableau, PowerBI...).
As far as I'm concerned it saved me a lot of time and effort, projecting/sorting/filtering... being available out of the box without having to code anything (especially with .net). It's my go to option for RESTful APIs on table like structures.
I had an interesting conversation with a contractor from one of the major outsourcing companies the other day. He has built restful APIs for many customers and when I asked if he used OData sometimes, he replied 'we don't do OData, we prefer Json' (sigh...).
So I guess one of the possible answers to your question is ignorance, many simply don't know OData or understand it...
I am beginning work on an individual project to bring an existing product out of the dark ages of classic ASP and into the light. My biggest decision to make before embarking on this lengthy journey is determining what frameworks and methodology I will implement for the new design.
Right now I am looking at MVC or MVVM (from what I gather this is just Silverlight?) for the web interface, Entity Framework or something I write myself as the model and MSSQL as the data.
Unfortunately I am just a fledgling programmer and I am not particularly aware of trends in the world of programming in general. I don't know what is just a passing fad and what technologies actually have lasting potential. I would really like to use something that is likely to remain relevant for some time. So I am looking to the professionals here for input on ideas that worked for you, pitfalls to watch out for and things to keep an eye on.
I appreciate any and all suggestions, keeping in mind that using the Microsoft and .Net is something of a prerequisite. I really want to make sure I am headed in the right direction before I start as this will probably take several months.
As for frameworks I personally suggest:
ASP.NET MVC 3 of MVC 4, depending on the question if beta software is allowed.
Entity Framework 4.3 or 5.0. 5.0 is a lot faster (is has auto compilation) but it's still a Release Candidate.
AutoMapper to map between Entities and ViewModels.
Ninject for dependency injection (useful if you want to write unit tests).
JQuery for stuff like clientside validation (integrates perfectly with ASP.NET MVC).
Possible some CSS framework like Bootstrap.
Maybe RestSharp so you can easily perform requests.
In case it's a cloud service (most SaaS are) and you'd like to host it on Azure (brilliant integration with the .NET stack) you'll need the Azure SDK.
As for software achitecture:
Use service layers
Use the repository patterns
Use ViewModels to pass to your view instead of entities
Set up a dependency injection container
That's my advice, I personally find this a golden combination for building enterprise applications (while not wasting too much time configuring lots of things).
Pitfalls:
I don't know if unit testing is really necessary. I should definately keep it in mind while setting up the architecture, but I personally choose to do that later because I don't even know if my product will succeed, so I can better put my time in building a fast Minimal Viable Product.
Don't assume anything. You can waste months of your precious time working on a cool feature that you think everyone will like, but often this is not the case. Do just the absolutely required minimum, and improve it later if your users like it.
I will add more to #Leon suggestions as I see those suggestion are great from application framework perspective, while I wanted to write here from cloud methodology perspective.
As you have chosen SaaS, definitely you are moving completely in Cloud while bring your application and data to cloud all together, that's great!!
There are several layers to any cloud application and to understand lets see what a cloud service stack look like. If we take an example of Windows Azure:
You have Compute, where your application runs with a web server (or not).
You have Azure table store which you can use to store key value pair in a row and then access them very fast.
You have Azure Queue allows decoupling of different parts of a cloud application, enabling cloud applications to be easily built with different technologies and easily scale with traffic needs.
You have Access Control Services to authenticate users through OpenID or AD
You have service bus to connect other services in cloud or on-premise at 3rd party.
You have Azure Blob storage to use as web based flat file server
You have Azure Cache (an in-memory cache build to scale in cloud)
You have SQL Azure as you cloud database
There are many more services which you can explorer and use
So when you decide to move your application from traditional web hosting to cloud you really have to look about how to take advantage of these different cloud services to scale your application when needed and save you lots of money.
With you application in Cloud you try something as below:
Keep you application logic as small as possible
Keep your static content outside the compute
Use cloud based cache for fast access as application scale out
Move data out of traditional RDBMS databases to NoSQL Framework (key-value pair, document etc to save money and flexibility), if possible and applicable
Take advantage of other available services to reduce application complexity
If you consider above aspect in your mind you will create a true cloud based application which will be fast and will save you money.
I work for a growing company that has several Rails-based SaaS applications. In it's growth, the company is going after larger clients, and one of the features that has come up as a requirement for these large companies is more sophisticated user management to ease the management of their thousands of users. Right now, client membership is simplistic and completely flat, and we've been asked to replace that with a customizable nested user-group-role management system capable of modeling any (reasonable) corporate hierarchy. We expect this to be a colossal undertaking.
To complicate matters, the company is trying to grow the business into a "platform" so we've taken on a few mortar projects to glue our existing and future applications together. One of these is a user-group-role management SOA project that all of our platform applications will use via web services rather than implementing their own.
I realize that implementing user-groups is not a new problem, so I'm interested in horror and success stories, and, of course, recommendations. What's the zeitgeist? Does anyone have any recommended reading? Should we roll our own RDBMS schema to handle this system, or should we implement something like LDAP?
If you roll your own RDBMS schema, the performance and scalability is all up to your implementation. Instead you could use LDAP. You dont need to implement the LDAP (or below x.500 directory service). There are existing servers that can be used like OpenLDAP. If your company can afford you could use eDirectory from Novell or AD from MS. eDirectory supports some nice feature called dynamic groups. You may read that from here http://www.novell.com/coolsolutions/feature/5414.html.