I have a web server application using Couchbase Server as its backend database.
Application comprises of few set of REST API's.
Now I have tested all my REST API's properly and deeply for all the scenarios, now I am in a dilemma if I should test my DB separately or not.
Because my REST API's gave me correct response (from DB) for all my input's passed to them.
So is there a need to separately test my DB using sql queries because it is the same thing which was done by API's.
And I am not considering the performance testing which is in my later scope. Just considering the functional testing.
Related
I am working on an enterprise-level system and am trying to understand if my idea is super inefficient.
Our company is looking to use GraphQL, and we want to use it as a way to assist the front-end client in retrieving data, but also as a data abstraction over our raw data. What I mean is:
If we have GraphQL closer to the client as one instance (that GraphQL server would sit in front of our domain REST services), but then we also have GraphQL sitting atop the data layer, does that present any issues?
I know the question might arise: "Why don't you have GraphQL over the domain services, and GraphQL over the data, but then federate those into a gateway and have clients pull from there!" But one of the tenants we are sticking to at our company is there must be an abstraction over our data. So, we either abstract that data via a REST API (which we do now), or we have GraphQL over the data and act as the abstraction.
So given that "data abstraction" requirement, I want to understand if there are any issues with the two "hops"/instances of GraphQL in the end-to-end flow?
This is a common pattern. We used this for our backend services, which received graphql on the domain layer and then used prisma for the data layer.
I have two recommendations from our experience.
Try, as best as possible, to auto-generate both your resolvers and your data API using a language, specific tool.
Do testing against the domain layer to make sure that nothing from the data layer slips through. It will be tempting to do simple "pass through" requests as the two schemas will often start off synchronized, and you may wind up accidentally passing through data you don't want going to the client.
(Shameless plug!) For the second one, Meeshkan does this sort of testing in an automated fashion, and there are plenty of testing frameworks you can use to execute hand-written tests as well (ie cucumber.
we can do CRUD operations using Entity framework but we can also do same CRUD operations using entity framework & Web Api.But why we need to use WEebApi.please give a real time Example..Try to tell answer without using it is light weight or to make restful services..
please differentiate between CRUD operation using entity framework and EF + webApi..what happen when we use one another.
Entity Framework is an object-relational mapper (O/RM) that helps with data access from DB.
It can be used to perform CRUD operations, execute Stored procedures, query views etc.
Web API is similar to web service. It is primarily used to communicate over HTTP which entity framework cannot do. Web API can receive requests over Http and call Data Access Layer (EF) to perform data access operations.
Hope it helps!!!
Entity Framework is an ORM. Assume you build a web application which functions on its own, has a UI and saves stuff to the db. In a simple scenario like this there is no point in trying to complicate things by adding an API into the mix, so your ORM is more than enough.
Now, imagine you have 2 applications, a web one and also a mobile app. They both take data and they both need to save that data to a database.
How do you achieve that without duplicating the work? This is when an API becomes needed.
You build an API, hide the database operations behind it and now both your web app and mobile can talk to one common layer and use the same data. This a very common scenario, if multiple apps need to share the same data.
There are of course other use cases, sometimes an entire business is focusing on providing data to clients and don't want to worry too much about how they're going to do it. They would provide an API, document the standards, secure their API and let clients use it as they need to.
I am trying to build a social networking site/app.After some research the conclusion I reached was to use a Graph Database. Neo4j is the most mature and used Graph database
Now I need to provide authentication and authorization to the database and I want to authenticate using OAuth so as to authenticate via facebook/google.
The problem I am facing is that I want to use the REST API which provides data on the basis of a person's authorization but I am not able to decide which framework/tool to use. I want this framework/tool to be fast,reliable and scalable.
The choice of a framework is quite a matter of taste on a person basis.
For Python you have Django and Spring for Java, both offers OAuth.
Now, this has nothing to do with your database, a user will never be connected to the database.
Also, a framework will not make your development life easier in the first 12 months, learning a framework takes time, and security is a hot topic and you need to learn all the little tricks of that specific framework.
In the meantime, you'll have to learn Neo4j and his integration with your framework.
I want this framework/tool to be fast,reliable and scalable
I think, depending of your development skills, that attending a fast, reliable and scalable application state with a framework you need to learn and a database you need to learn, this should take approximately two years.
We have a web2py application that we want to connect to an EmberJS client. The idea is to use the responsive capabilities of EmberJS to keep the client updated writing minimal code.
We have (REST) primitives which are in charge of creating / updating the underlying datastore (CouchDB). These primitives are sometimes complex and covering corner cases, involving the creation of several documents, connecting them, validating configuration parameters, ... This is implemented in the backend. We would like to avoid duplicating the full modelling of the data in our EmberJS application, and avoid duplicating the logic implemented by those primitives.
I have some questions:
does it make sense in EmberJS to just model a subset of the data in the documents? We would just create models for the small amount of properties that the user is able to interact with. The client would not see the full CouchDB documents, just the data necessary for display / interaction.
is it possible to connect EmberJS to a REST interface, without having to fully model the underlying data in the database?
does it make sense in EmberJS to just model a subset of the data in the documents?
Yes. There is no need to create ember models for objects/properties that user will not need to interact with.
is it possible to connect EmberJS to a REST interface, without having to fully model the underlying data in the database?
Definitely that is possible, it's a fairly common use case. The best way to get started is by building a small MVP that works with just couple of models. Once you've got that wired up it will be easy to add more domain objects.
The tricky part (especially at first) will be mapping your rest endpoints to the ember-data REST adapter. The adapter will work out-of-box with some REST endpoints - see the REST Adapter - but connecting a CouchDB datastore will probably require some customization. The tools for this are still evolving, have a look at ember-data integration tests to see what is available.
I am thinking in using MongoDB as my main database. However, my app is
fully in JavaScript and I wanted to use the REST API, client side.
I still can't understand what security mechanisms can I use in order to
make a JS call to the database without revealing all the data to all the
users.
Please advice on this matter.
Regards,
Donald
First of all, you can enable database auth which will make the REST interface require authentication if connected to from a remote machine.
That said, it's a very bad idea to expose your database like you suggest. Build a persistence abstraction layer in a server technology you're comfortable with (node.js for example) and put all security constraints and authentication there. The advantages are numerous :
You can keep your API stable even if the MongoDB one changes. You can even replace it with another persistence solution if the need arises in most cases.
You can limit the load a single client can put on your database. If you expose the database directly there's very little you can do to avoid people doing expensive queries or even potentially corrupting writes.
You can often do smart app-side caching and optimization that is not possible if every client directly accesses the database (this depends a bit on the app in question though).
Check out Sleepy.Mongoose, it's a REST API interface for MongoDB. I haven't tried it, but it appears to support standard MongoDB authentication.
MongoLab has MongoDB database hosting with a REST API that can be accessed client side, they even through in some jQuery based examples in their support documentation. That said, Remon is right that you sacrifice any security by doing so because you're making your API key public.
RESTHeart is a Web API for MongoDB.
It provides application level authorization and authentication.
Check the security documentation section.
Also some example applications are available on github:
blog example (using AngularJs via $htpp service)
notes example (using AngularJs via Restangular service)