Is it possible to execute server side code (something like Parse "Cloud Code") with Apigee, as backend for a mobile app as client?
I'd want to use the out of the box "App Services" functionality, but perform some extra stuff (like updating data) from the server side,
The only (naive?) way I can think of is this:
Have my own server running.
The mobile app uses standard "App Services" API on Apigee
If necessary, the client calls
some custom API on my server,
which lets my server call Apigee via REST to fetch data, calculate some results, and post the updated data Apigee
and then returns the result to the client
Sounds a bit complicated (especially in terms of handling authentication) - are there any best practices to achieve something like I described?
Thanks!
Consider App Services as your database in the cloud to which you can talk using APIs. Therefore, you really don't need that server in the between unless you are doing some heavy lifting in it. You could make that API call directly from the app.
Even if you want to have a back end server for your app, you can leverage the node.js functionality that Apigee Edge provides and have a server up and running in the cloud in quick time. More info can be found here
If you want to do server side validation, you should use a Node.js proxy that incorporates Usergrid. This will allow you to perform a query on the database and do processing of the results. Check out this presentation: https://speakerdeck.com/timanglade/coders-workshop-at-i-apis. In particular, see Section 7, which discusses using Usergrid and Node.js.
Related
We are trying to figure out best design practice while using hyper-ledger composer. We have following questions :
1) if We are using composer-rest-server, then will have to manage two server side components.
i) running composer-rest-server ii) running application which will send request to composer-rest-server to communicate to network.
Isn't it overhead? what additional advantages we are getting by using composer-rest-server? in fact, probably client will have to authenticate two times i guess.
2) If we are using JavaScript SDK, then will have to manage only one server side application, kindly correct me in case of misunderstanding.
3) When i generated angularjs application using yo generator, its also asking me information of composer-rest-server, but I am not planning to use composer-rest-server and want to use 'composer-client' and 'composer-admin' only.
Yes, there will be some overhead of running the composer-rest-server in its own process, however it will allow you to secure and scale your rest servers independent of your application. Depending on your scenario that may be an overhead worth paying.
Another option would be to generate a LoopBack application (using the lb tools) that uses the loopback-connector-composer LoopBack connector directly. This may give you access to the underlying Express server and would allow you to merge your application and the REST server.
You are correct, however you would have to build the REST API for your business network yourself, and manage authentication and certificates.
The generated Angular application uses the REST API exposed by the composer-rest-server to interact with HLF.
Here is a DRAFT topology diagram that I am working on for contribution to the documentation.
I see that rethinkdb now has an app server called horizon and it's examples include a lot of client apps without any backend server code.
If I wanted to create a REST api service with rethinkdb - does horizon still add value or should I just create a standard node.js rest api using rethinkdb libraries directly?
I see that horizon has some authentication, authorization and permissions built in which could be useful but I'm not sure if turning it into an api instead of a standard web app is making horizon bend into something it's not supposed to be.
If I wanted to create a REST api service with rethinkdb - does horizon
still add value
No, if all you want is a REST API endpoint mapping CRUD operations onto your RethinkDB data, then Horizon won't help you there.
Horizon is great if you want websocket API w/ "real-time" features and plan to use the Horizon client in the browser.
Horizon is opinionated in how it handles users and permissions (it enforces them on the server side using different users/permissions for each app instead of the RethinkDB users table).
# RethinkDB
r.db('rethinkdb').table('users')
r.db('rethinkdb').table('permissions')
# Horizon
r.db('myapp_internal').table('users')
r.db('myapp_internal').table('users_auth')
I'm currently playing around with a stack that uses feathers to design common services that can be exposed over a REST or websocket transport. Its more complex, but I might use both feathers and Horizon, but there will be some work to map permissions correctly across both endpoints. (Plus schema enforcement...) Feathers supports various authentication providers that return JWT which you could then pass to horizon (if you set the same secret_key)...
If you don't need the real-time features in your database, you might want to check out PostgREST as it has out of the box JWT authentication and uses actual database roles for row level authorization. "One source of truth". You could use that together with PostGraphQL if you want both REST and GraphQL! Plus you can store JSON data in columns these days so its all good!
So many options!
Good luck!
You can embed Horizon in a node app and only use a subset of its features: http://horizon.io/docs/embed/ . You should be able to piggyback on the authentication pretty easily. It would be harder to piggyback on the permissions if you're implementing your own REST API, because the permissions system only controls access to collections.
Personally I suspect it will be more trouble than it's worth if you're embedding it just for the authentication.
I'm contemplating to use Parse as a platform for my app, as I'm trying to avoid creating and managing the cloud infrastructure myself.
For the sake of simplicity let's say that my app will hook into an Exchange Server and will need to leverage some hosted Machine Learning service to categorize my e-mail and report on insights found.
I'm assuming that Parse would store my core data, while the hosted ML will store the "Big Data" associated with processing for insights.
I'm also expecting my app to receive push notifications generated by the hosted ML service.
Does this sound like a plausible way to go about it and leverage Parse, or am I better off developing the backend myself?
I think parse.com is the right place for you requirements, because they have everything you need like storage of core data, push notifications, cloud module which can be integrated with heroku, social integration, user management functionalities.
They also have large set of client libraries for desktop and mobile apps (node,java,.net etc...) also they have libraries of embedded devices.
The biggest advantage is that everything is setup, and you are focused on software development not on infrastructure things. This is my opinion.
I've been experimenting with the above stack and so far was really impressed. Seems like a viable path forward. The Cloud Code capability of Parse is very solid, and easy to work with. If you want to run services outside of Parse code this us also possible : just issue REST calls.
I'm currently developing a WP7 app, and I'd like it to talk with my SQL Azure database. I know there are currently two ways of doing it:
Talk to a WCF Service hosted on my web server.
Use oData to communicate with my database.
I don't know what's the pros and cons between the both of them, but I know that using the first method involves two remote calls: one: to the web server, and two: from the web server to SQL Azure. Would using oData allow me to directly communicate with my SQL Azure database? Does SQL Azure provide a REST interface for my WP7 client to work with?
If you use the WCF service approach and host the service on our web server (i.e. not in an Azure Web Role) then yes there will be two higher latency hops across the network. However the WCF service does have the benefit of allowing you to provide your own security approach for your mobile clients. I suspect that this app will be used by more than just a couple of people? If you take the approach of talking directly to the SQL Azure oData endpoint then you will really struggle with Authetnication and Authorization. It's not really designed for supporting your scenario.
The other thing to note with the SQL Azure oData endpoint is that it never left SQL Azure Labs; i.e. it was never actually shipped as part of the product and the Labs implementation is end of lifed and grandfathered to existing users only.
I know that doesn't really answer your question; the short answer is that there is no RESTful endpoint that you can access to talk directly to SQL Azure. The long answer is that even when there was one you probably didn't want to use it.
Without knowing more about your app it's a little hard to give guidance as to exactly what you should be doing. If you can provide a bit more detail I can provide some advice as to which Azure data storage technology would be best suited.
I have this webservice at work. For that webservice our department have developed a client to consume the webservice.
What we want to prevent is, that they develop any other client to consume it.
Is there any algorithm, practice that we can improve in our client and webservice communication to validate that the consuming client is our application?
I have an idea, that we can develop an encrypting algorithm about the time (5 seconds of grace) that must match with the calculated on server.
But i want to be sure, there is no best practice for that... or if it still a good idea...
(sorry about my english)
I think part of the point of web services (SOAP or REST based, for example) is to publish an interface that will let your service potentially be used by a variety of client implementations (interoperability is one of the motivations for web services).
If you want to lock your service to be used by your client, the only benefit of having it as a "web service" is probably the tools and libraries with which you've implemented it. You may want to consider whether this was worthwhile (it's possible indeed).
If you distribute your client application, chances are that whatever protection mechanism that may ensure the requests come from that client will have to be embedded with this client. Therefore whatever secret mechanism you embed will probably be only obfuscated to a certain point, but breakable by more advanced users.
What you are looking for is known as "authentication".
You need application authentication. For Web based application and services try looking into 2-legged OAuth. In OAuth You give out an id and a secret for every client app which accesses your service and every message is signed for extra security.