I'm looking into Volt as an option for building an Admin interface to our REST API. The API is a separate application. I would like the Admin application to persist data to the API but also store it's own data that is irrelevant to the API (such as admin users and notes on the API data objects) locally.
Is there a way to sync each local change in the Admin with our remote API, like a callback, for example? Or do I need to wait until the Data Provider API is ready as mentioned in the most recent Volt blog post (as of writing)?
So this is a fairly common thing, so I think long term the solution will be to support multiple stores in an app and have a REST data provider that you can extend. However that might be a while before that's ready. In the mean time, you can always load and save data via tasks. (I realize its not ideal, but it will work right now) Let me know if you need more info on using tasks to load and save. I'll add the REST data provider to the TODO list.
Related
Around a year ago I made an iOS application that finds restaurants near your location of any type and displays information about them. I made a web service call using the FourSquare api to get all the data which was returned in json format and then I parsed it and displayed the information on the UI of the app. Now I want to make an android application using Xamarin.Android since I am learning working with Xamarin studios and C#. When I make a Xamarin.Android application and go to packages then add packages I see there is a Foursquare api package that has a .NET wrapper around it. Here is the website url:
https://www.nuget.org/packages/Foursquare.Api/
So my question is how does this work? Does adding this package mean I don't have to make a web serivce call anymore, instead all the data is stored inside this package and I just have to get all the data the same way I get information from a local database? What are the advantages of using this package instead of just making a web service call to Foursquare?
Think of it this way:
This Foursquare API is simply a .NET wrapper of the web service that you want to use. Thus, somebody has gone ahead and done all of the hard work for you so you can simply consume the returned data in your applications.
What does this mean for you?
Well it means that you don't have to write any REST consumption code and you can focus more on the actual application and any business logic that you need to implement based on the Foursquare objects.
To not confuse any further, this data would come the same way as if you wrote your own web service to access the data from the Foursquare API endpoint.
Advantages:
Already written for you
You don't need to know your way around their REST API
Usually follows best practices per language so it's easy to consume (Objects created, methods, etc)
Disadvantages:
REST endpoint might be updated and not reflect in the package until it's updated
Any bugs/issues in the framework can be hard to workaround if the project is not open source
Could be a lack of documentation on how to use the wrapper
My single page app is hosted on Google's cloudstore. I love that I don't have to worry about a server. The app is, naturally, javascript heavy.
Now I would like to add a feature where users can store some data, generate a link to be shared with others and retrieve stored data. Think of a pastebin where some snippet of text is saved and a unique link is generated to be shared with others.
In fact, if it helps, think of this as my attempt to create a pastebin without having to setup a server.
It looks like Google's cloud datastore nosql solution is what I want. Given a key, it will return a snippet of text. However, all the examples on the documentation page imply that I have to setup a back end service using python, node, etc.
Questions:
Can't I just read and write from a web page, perhaps using ajax style http call (since I need to get and put text snippets once data has already been loaded)? I believe I can take care of cross-origin issues by changing some configs in the cloudstore static website server.
Obviously I don't want to serve any encryption keys from the web page. I'm hoping that since my site is served from Google as well, I can configure the nosql service handle permissions intelligently for this scenario.
Is there any documentation which shows how to do this correctly?
Google Datastore is not supposed to be used from client side, it's a served side database. You cannot do that w/o having server side code to authenticate, authorize and validate db related requests.
But there're an alternative. Firebase is a ready to use backend for client side applications, including Javascript apps. It's a separate project, that belongs to Google but not (yet?) part of Google Cloud. Take a look - https://www.firebase.com/
Although the API Rest is still beta, it is possible now to connect from a web client or anything RESTful capabilities. https://cloud.google.com/datastore/reference/rest/
As stated. I am using ruby to perform my task. I am to create a webpage that takes in user input and makes calls using the API back and forth. However, I am yet to understand how to deal with these APIs...
When you consume the API you are essentially making use of the service. So you are sending data and are, potentially, getting something back.
When you write a rest client, you are essentially writing an entity which will consume the API. The rest client could also provide some functionality to ease the consumption of the API, for instance if your API requires a time stamp, the rest client could automatically provide the current time stamp, or else provide the user with a nice UI control to do so easily, rather than type something like this: 22-10-2002 12:10:11 GMT.
The client itself can take different forms. It could be a simple page on a web page, or a more complex desktop or mobile application.
So, I'm starting out building a social network web app. I'm looking into how to fit the parts of my stack together and I'm looking for some guidance about what various frameworks will allow me to do. My current stack idea is to have:
Firebase JSON API: serving user, post, comment, and all the other data
EmberFire: to plug that API into EmberJS
EmberJS: my front-end MVC (because I'm new to MVC and Ember seems the most accessible)
What I'm stumbling on at the moment is how I'm going to implement users with this stack. I've looked at basic authentication stuff but I haven't found anything that would allow me to allow certain actions and views for certain users and not others - the basics of a social network really.
Is it sensible to be doing this stuff in front-end MVC? If so what should I be using to do authentication/personalisation? If not, should I just be doing a PHP/SQL setup? I'd rather avoid that because my skills are all front-end.
If you are just getting started, Firebase is a great service to learn on due to their 'back end as a service' model - you will spend more time building/modeling your data and less time running/installing. Not that you won't want to learn more about that later, but it lets you focus on one piece at a time.
From an access perspective, JS/NoSQL vs PHP/MySQL isn't going to be the issue. They each have their own security requirements - it's more that PHP/MySQL has had more time to establish those rules. Additionally, Firebase being a hosted service has it's own set of requirements.
Firebase security rules are a little weird when you first look at them, but they begin to make some sense after you sit with them for a bit. The Firebase docs are actually a pretty great resource. https://www.firebase.com/docs/security/
Basically, if you use a Firebase 'login provider' it makes Firebase act as both a database and a authentication manager, and the combo helps keep users 'fenced' to where you want them. You can use data from other paths, variables, validation rules, etc. You can even make a 'custom login provider' if you need to integrate with an existing one.
Finally, on the client end, your view can respond to whatever Firebase returns - if a user does 'hack' their way through to a page they shouldn't be on client side, no data is returned anyways and no submitted information would be allowed because of the rules.
I am trying to make a web app using ExpressJS and Coffeescript that pulls data from Amazon, LastFM, and Bing's web API's.
Users can request data such as the prices for a specific album from a specific band, upcoming concert times and locations for a band, etc... stuff like that.
My question is: should I make these API calls client-side using jQuery and getJSON or should they be server-side? I've done client-side requests; how would I even make an API call from the server side?
I just want to know what the best practice is, and also if someone could point me in the right direction for making server-side API requests, that would be very helpful.
Thanks!
There's are two key considerations for this question:
Do calls incur any data access? Are the results just going to be written to the screen?
How & where do you plan to handle errors? How do you handle throttling?
Item #2 is really important here because web services go down all of the time for a whole host of reasons. Your calls to Bing, Amazon & Last FM will fail probably 1% or 0.1% of the time (based on my experiences here).
To make requests users server-side JS you probably want to take a look at the Request package on NPM.
It's often good to abstract away your storage and dependent services to isolate changes and offer a consolidated and consistent web api for your application. But sometimes, if you have a good hypermedia web api (RESTful responses link to other resources), you could reference a resource link from another service in the response from your service (ex: SO request could reference gravatar image/resource of user). There's no one size fits all - it depends on whether you want to encapsulate the dependency or integrate with it.
It might be beneficial to make the web-api requests from your service exposed via expressjs as your own web-apis.
Making http web-api requests is easy from node. Here's another SO post covering that:
HTTP GET Request in Node.js Express
well, the way you describe it I think you may want to fetch data from amazon, lastfm and so on, process it with node, save it in your database and provide your own api.
you can use node's http.request() to fetch the data and build your own rest api with express.js