I'm working on a project in my University, and we want to use an Apache OpenWhisk service for our student projects. I already set up the OpenWhisk service and add some components like Java, NodeJS and Python, everything works fine. My next step is to set up a webserver, so our students can use this instances to publish their websites (written in HTML, PHP, Java Script). I have already searched for this topic but don't found anything.
Hopefully someone can help me.
There are several ways to accomplish this and it depends on how far you want to go in the serverless direction.
For example this repo https://github.com/jthomas/express_example is a way to package an existing web server inside a function. This is another variation on the same https://github.com/IBM/expressjs-openwhisk.
If you want the students to implement a serverless web application from scratch, then generally every API end point becomes a function using web actions https://github.com/apache/openwhisk/blob/master/docs/webactions.md.
You can use web actions to also serve static content (html, js, css) by inlining those files and returning them as part of the function result. This is not ideal and should be done from a CDN instead. OpenWhisk itself does not offer object storage/CDN support but you can use S3 or Google buckets to accomplish the same.
Some serverless platforms like Netlify or Nimbella might be suitable. The latter provides an integrated CDN + OpenWhisk to implement entire web applications including JAMstack.
Related
Can anyone please tell me what is the difference between:
aws-sdk/clients/appsync, and aws-appsync
According to the doc, aws-sdk/clients/appsync is used because just including aws-sdk is too large when we just need appsync, we use aws-sdk/clients/appsync.
However, aws-appsync seems also doing the same thing. When I create a client using aws-sdk/clients/appsync, there is no hydrated() function while aws-appsync has.
So
Why can't we simplify everything by just using aws-sdk/clients/<any_aws_package> and break everything that did not use it?
What is the point of separating something that is similar?
Thank you very much in advance for all your help.
difference between: aws-sdk/clients/appsync, and aws-appsync
GraphQL originated at Facebook and the React/React Native apps used react-apollo to talk to the GraphQL based APIs.
AWS AppSync is the AWS offering for GraphQL. aws-sdk/clients/appsync is the JS SDK to invoke various AppSync management/control APIs (like create GraphQL API, create data source etc). Not sure if they also provided apis to consume the GraphQL based api.
aws-appsync is the way to consume AppSync backed GraphQL APIs. It plays well with react-apollo which is now moved to apollo-client.
There is another high level JS library from AWS Amplify, which is used to consume AppSync backed GraphQL APIs.
aws-sdk/clients/appsync is used because just including aws-sdk is too
large
The initial release of the aws-sdk (Github repo here) contained the clients for all the AWS services and more. You need to install aws-sdk and you can talk to pretty much all the AWS services by initialising the clients for them. Obvisously it was not so good in terms of packaging JS bundles, the library was also not very modular.
Now the latest version V3 (rewritten using TypeScript) which is GA now, moves the clients to individual npm packages i.e. you need to only install the client you need e.g. npm i #aws-sdk/client-appsync instead of npm i aws-sdk. Learn more about it here. If you are getting started use the V3 packages.
Why can't we simplify everything by just using
aws-sdk/clients/<any_aws_package> and break everything that did not
use it?
It is the case with the V3 JS SDK.
What is the point of separating something that is similar?
They are not similar. One is used to consume the GraphQL based APIs (provided by AppSync) and the other is to manage AppSync itself. The V3 packages follow this very strictly while the earlier versions may have some utility code/ high level abstractions along with the core AWS apis.
I'm new to building APIs, I made the first one using an MVC framework: codeigniter, with chris kacerguis rest implementation.
I'm not really sure this was the best think to do because I believe maybe the framework is not that "slim" or light just to API's purposes.
I plan to do a mobile App, an admin and a website so the three can consume the Api's services.
Is it a bad idea to have the API, the website and the admin on the same project? which are the pros and cons? or the best architectural approach?
Otherwise I will have: One Codeigniter project for the API and Another Codeigniter project for website and admin
thanks
You can create folders in "controllers" folder to organize your project and use the same project/env configuration :
controllers/Home.php
controllers/api/MyApi.php
controllers/admin/Admin.php
Edit : You will share models and libraries too.
In my project I realized 2 types of controller - REST and API. Admin js gui work with REST, other world work with API. You can do it simply with silex framework, a little brother of symfony.
The purpose of building a REST API so that you only have to build one project for your business model. This allows you to construct any number of applications on any platform, only requiring you to consume the API in different ways. This essentially separates/decouples the user interface from the business logic, and vice versa.
You should create separate projects for the REST API and each UI project should also be separated projects. This allows you to change the underlying code, language and platform in any one of the projects without breaking any of the other projects as long as the API signatures remain the same.
For example, you could have a live version of your website built using Codeignitor while developing another septate project using AngularJS. When your AngularJS project is complete you would simply swap out the project on your server (or create an entirely new website or server) still allowing you to use the other if required. Additionally, you may decide that you would like to move the API onto a different platform, language or database, develope it and swap the implementation when finished causing no changes to any of your UI projects assuming you have not changed the API signatures.
I own a Play 2.1 application.
Initially, I used the default template mechanisms from Play 2.1 until I .. learned AngularJS.
Now, I clearly want my client side to be an AngularJS app.
However, while surfing the net, I find there are no clear way to achieve it:
Letting Play behave as a simple RESTful application (deleting the view folder) and making a totally distinct project to build the view (AngularJS app initialized by grunt.js).
Advantage: Likely to be less messy, and front and backend teams would work easily separately.
Drawback: Need another HTTP server for the AngularJS app.
Try to totally integrate AngularJS app with the traditional Play's workflow.
Drawback: With a pretty complex framework like AngularJS, it would lead to a confusion of templates managementfor instance : scala.html (for Play) / tpl.html (for Angular) ... => messy.
Making a custom folder within the play project but distinct from the initial folders created by the Play scaffolding. Let's call it myangularview instead of traditional view for instance. Then, publish static contents generated by grunt.js into the Play's public folder, in order to be reachable from browser through Play's routing.
Advantage: SRP between components is still fairly respected and no need to use another light HTTP server for the client-side like in 1.
I pointed out my own views of advantage and drawbacks.
What would be a great way to achieve the combination of Play with Angular?
Yes, I'm answering to my own question :)
I came across this way of doing:
http://jeff.konowit.ch/posts/yeoman-rails-angular/
Rails?? No matter the framework is, the need remains exactly same.
It advocates a real separation between APIs (backend side), and front-end side (in this case making AJAX calls to backend server).
Thus, what I've learned is:
During development phase, a developer would use two servers: localhost on two distinct ports.
During production phase, the front-end elements would be encompassed into the whole backend side (the article would deal with a kind public folder, aiming to serve static contents: HTML, angular templates (for instance), CSS etc... Advantage? => dealing with a one and unique serving server's APIs exposition as well as static assets for the UI.
With this organization, some tools like Yeoman would be able to bring some really awesome handy things to developers like for instance: the livereload feature. :):)
Of course, during development phase, we end up with two different domains, (localhost:3000 and localhost:9000 for instance) causing issues for traditional ajax requests. Then, as the article points out, a proxy may be really useful.
I really find this whole practice very elegant and pleasant to work with.
There was an interesting discussion on the play mailinglist a couple of days ago about frontend-stack/solution, could be something in it for you, quite some people using angular it seems: https://groups.google.com/forum/#!searchin/play-framework/frontend/play-framework/IKdOowvRH0s/tQsD9zp--5oJ
I'd like to start practicing JS server-based stuff in a real-world environment (not localhost) and AWS seems to be the most economical way to do this. And I'd like to start by using Backbone in conjunction with REST.
If I do this, is REST out-of-the-box ready on AWS and it's just a matter of throwing my Backbone code on the server? Or is it a matter of configuring the REST API on AWS?
Thanks in advance!!!!
As the comments indicated, web applications are broken up in to two parts, the client and the server, and Backbone is an exclusively a client-side library ...
... well, almost. There is a server-side Javascript web framework called Node.js, and if you really wanted you could use Backbone on it. Alternatively you could run a more traditional server-side language/framework like Ruby/Rails, Python/Django, etc. If you are using AWS's EC2 service you basically get your own computer to do what you want with, and you can use Node, Django, or whatever else to write a REST-ful webservice that your client-side code can use.
Looking for a recommendation of which framework/web server to go with on Linux. The idea is to build database backed RESTful web services.
I know Java, c++, c# (irrelevant I guess on linux) and C. Okay with developing in any of those.
Here is a table of frameworks that have varying degrees of support for REST and the languages they use.
You might want to check out RESTx. It is multi lingual: You can write code in Java, Python (server-side JavaScript coming soon). RESTx is specifically a platform for the creation of RESTful resources and web services. It is NOT a traditional application framework. DB backed web services are actually a specialty of RESTx: You identify the reusable components you want (in this case a JDBC capable DB access component), and then just configure it through the RESTful API or by filling out a small form in a browser. As a result, you get a new RESTful web service, which encapsulates the query you specified when creating the new resource.
I'm the lead developer on RESTx, so if you have any questions, please contact me or visit our forums.
If I were you I would go with Ruby 1.9.2 + Rails 3
they're fun and you get to learn something new
ubuntu specific install guide: http://web2linux.com/installing-rails-3-on-ubuntu-10-04-lucid-lynx/
official RoR intro: http://edgeguides.rubyonrails.org/getting_started.html