I am new to the serverless application model for the web and want to understand a few things. I went through the AWS Building your first serverless tutorial and have a couple of questions. I am used to the MVC model of LEMP or using .NET.
In the tutorial all the pages that were accessed were static html like app.com/login.html and app.com/ride.html. Is this the way things are done in the serverless world? I get it that the lamdba and rest api add the dynamic content.
How do I name the pages in my browser to go from app.com/ride.html to app.com/ride-to-london instead?
Is Lamdba essentially like just writing Node.js?
Is there a way if they are all individual html pages to make one global layout? Any layout template advice would be helpful.
I want a multi page application like say this site vs Gmail (less ajaxy) and more like a blog. How is this accomplished? A tutorial on this would be helfpul.
Thanks.
1) you can use a modern front end framework like Angular, React, Vue, etc. and host your website statically on S3. Check
Hosting a Static Website on Amazon S3 for more info. Your static website will then interact via HTTP with API Gateway. You then map your lambda functions to events from API Gateway. Check this tutorial
2) depends on how the framework chosen on step 1) deals with it
3) it can be NodeJS, Go, Python and other supported languages if you wish. Each microservice (lambda function) can be written in a separate language. For more info, see the supported languages at
Lambda FAQ
4) again, depends on the framework of your choice
5) this you’ll have to lookup for yourself, but anything like "Blog Tutorial in {Framework of Choice} should do it. Here's an example using React
Let's now say you have deployed your application, you can then make use of other Events supported by AWS. Since you're creating a Blog example, you may want to upload pictures to your Post itself so it looks fancy, but you don't want users on mobile phones to load these high resolution pictures when they are only browsing through your Blog, so you could make use of an S3 Event to generate a thumbnail for your picture, so they can have a preview before actually clicking to see the content. The possibilities are endless.
Using a Serverless model to create applications also enables building event-driven applications out of the box. These applications are highly available and auto-scalable by default.
Related
I am working on a project to create an online medical booking system using Dialogflow as the frontend to provide users with a more personable experience.
So far I have come up with an ideal stack PIC. I plan to have it hosted on AWS (or GCP). However, I am new to Dialogflow but I know it is a very powerful platform. My two criteria are: (A) A stack that makes it easy to personalize frontend UI display and (B) Scalability, I am starting with a web app but would like to also develop an iOS app.
I have two questions: (1) Would you change anything in the stack? and (2) Is there a way to change the name of the bot each time user visits (to make it more "real")?
Super appreciative of you guys expert opinion :)
IMHO, I've found GCP to be easier to use than AWS, since Google handles SSL encryption with .app domains, while AWS requires a more manual solution. Google Cloud also offers a terminal window inside a Chrome tab, which can be a fun experience. So, for hosting, I recommend Google Cloud, unless AWS has a unique feature that applies to your personal circumstances.
Personally, I prefer Angular to React, but Angular, React, and VueJS are all fine choices for a front-end framework on a web app. Your choice of these probably depends on which framework you already know, or (if you plan to outsource development) which language you can use to hire better engineering talent.
For my own projects, I use Express and Node on the server side, instead of GraphQL and Prisma. Your call there.
Good luck!
I am developing mobile apps using phonegap.
My mobile app will have same functionality as like my joomla-jomsocial website.
I have to access web services using jQuery.ajax as I am using javascript and html only.
Are there any ready web services or APIs in joomla-jomsocial?
Joomla! only recently formed a working group for "Web Services" and I think you won't see any outcomes from that for a while.
As #Riccardo Zom, say your best bet will be to access the barest formats you can from each component type using the format/tmpl parameters.
If you're motivated enough you could extend existing components (core and otherwise) to return the desired format (e.g. json), in that case you should read Louis Landry's note on the changes from 1.5 era XML-RPC feature set to the 1.6/2.5 mechanism.
If you're still looking after that you may be interested in the "Joomla! API - Generic RESTful API framework for Joomla! 2.5" by Rafael Corral, it's a component (com_api) that provides a framework for creating a RESTful API for a Joomla! 2.5 site.
Unless you want to rewrite the whole component logic in your html app, you might be happy with grabbing the component output without all the extra page markup i.e. get the bare html returned from the component: just add &format=raw to the query; if you want libraries and css to be returned as well, instead add &tmpl=component
There is also (limited) support for &format=json in some core components.
I'm writing Django application (social network) and thinking about dividing monolithic project to two projects: UI and API. For example, Django will be used only to render pages, interacting with and taking data from API, written on web.py.
Pros are following:
I can develop and test API independently.
In the future, other UI can appears (mobile, for example), it will require service.
I plan to outsource web UI developing, so, if my application will have two modules, I can provide outside only UI one, not sharing logic of application.
Cons are following:
I'm working alone, and developing two projects are harder, then one.
I will not be able to use cool Django admin panel. I will need to write my own.
web.py is more low-level comparing with Django.
It's like a brain dump, but I will be really appreciated if you share your experience in creating web application with UI module and independent API module.
Update (more specific question, as Mike asked)
What Python framework will you use for creating REST API of social network, which can be used by different client applications? Is using web.py that returns JSON only and rendering it by Django for web is good idea?
Thanks,
Boris.
I've been in a situation similar to yours. I ended up writing both, the UI and the API part in Django. Currently, I am serving them both out of the same process/project. You mentioned you wanted to be able to outsource the UI development, but do hear me out.
In the meantime, I have used django-piston to implement the RESTful front end, but a bit of preparation went into it:
Encapsulate all DB and ORM accesses into a library. You can do that either for your entire project, or on an app by app basis. The library is not just a low-level wrapper around your DB accesses, but also can be for higher-level 'questions', such as "all_comments_posted_by_friends()" or something. This accomplishes two things:
You can call your pre-canned queries from UI views as well as API views without having to re-implement them in multiple places.
You will later be able to replace some - if not all - of the underlying DB logic if you ever feel like going to a NoSQL database, for example, to some other distributed storage model. You can setup your entire app of this ahead of time, without actually having to worry about the complicated details of this right at the start.
The authentication layer for the API was able to accept an HMAC/token based header for programmatic access and normal Django auth. I setup the views in such a way that they would render plain JSON for the programmatic clients (based on content-type), and would render the data structure in HTML (with clickable links and clickable docstrings) if browsed by a human from a browser. This makes it possible that the API is fully explorable and clickable by a human without having to read any docs, while at the same time it can be easily processed by a client just via JSON.
On effect, the database layer I build serves as the internal API. This same database layer can be used from multiple applications, multiple processes, if you wish to do so. The UI views and the REST views were both implemented in Django. They can either be in the same process or in separate processes (as long as they have access to the same database right now).
This is quite a concept idea. I would like to create a website that can be extend by different programmer a bit "a la facebook"
Let's me explain i want to develop a very simple core application that for example would store images and i want to develop or allow external developer to develop web app that would be able to act on the image i can take this example of an OS that would store files and you can "install" different program for example to view the files or edit.
How can i reproduce the model in the Web / cloud plateform using API ?
I hope this question make sense to any body.
Thank you by advance
Web Services. Try looking up REST and SOAP.
The Semantic Web is trying to solve this by publishing structured data with common ontologies.
See this example, describing the user's photos as RDF, using the FOAF ontology:
http://www.semanticoverflow.com/questions/201/describing-in-a-foaf-file-assets-of-a-user-photo-album-video-album-etc
The Semantic Overflow website is an excelent resource to find out more about the semantic web in general, and how creating webservices that use a common set of interfaces can allow a greater reach, because tools don't have to be specific to a website.
I will be developing a mobile app (iPhone) and a web based app (Django) soon. For the mobile app I will be creating a REST api (most likely using Django) to send data back and forth from phone to server.
When I comes time to create the web based version does it make sense to just create it as any other client of the api. In other words both the mobile app and the web app will get there data from an external API over HTTP. Or should the web based app have direct access to the database that the api is using and just get its data that way?
Break it into three "sections". The first uses a Python API to manipulate the database. The second interfaces your REST API with your Python API. The third talks web and uses the Python API.
I would create the web application to serve the API to the mobile client. That is, give the web based application direct access to the database. This will simplify your XML / JSON RESTful resource access.
I would say no, don't use the API for the HTML version. If you design your Django well, you can end up with less code than using the API for the HTML version. You also get to retain the ability to have a web designer work with the Django templates whenever the boss wants the spelling changed on something.
I'd suggest trying to define a base app for your iPhone app to interface with, and then extend that within a second app for the HTML version. App1 would have all of your models (including business logic), and a views.py for processing the data to/from the iPhone. Then create App2 which uses App1.models, but creates its own views.py. With any luck, you'll find yourself with the ability to change nothing but the template used to render the output, so you can reuse your views by passing the template as an argument.
For example:
App1.views:
def list(request, template="list.json"):
list = Model.objects.filter(deleted=False).filter(user=request.user)
list.reverse()
## Lots of other logic to work on the list.
return render_to_response(template, {list: list,})
App2.views:
def list(request, template="list.html"):
return App1.views.list(request, template=template)
I think the answer to this question has changed over time. A year ago when asked it was probably still too much hassle to do this, but now I'd definitely say yes - using your API as the basis is the smart thing to do. As Web sites use more HTML5 and Mobile apps get smarter it really makes sense to have all your "UIs" read/writing from the same API layer. This will give you much more flexibility in the future.