I am am making an app for iOS & Android whose frontend UI is ready. Now I wanted to learn some server side coding to connect my backend with Amazon services.
MY app will feature 1.image upload & download 2. storing of data and meta data 3. user registration and stuff
I have no clear idea about server side and cloud coding ? so want you guys push me a bit from where should I begin and how should I begin to make the above features for my app working ?
It sounds like you are looking to do mobile app development that works with cloud datastores.
Here are a few blogs that you can take a look at get started with:
http://mobile.awsblog.com/post/TxERCU1UMRFNPB/DynamoDB-on-Mobile-Part-5-Fine-Grained-Access-Control
The above blog post talks about using AWS Mobile SDKs with DynamoDB. In general, mobile.awsblog.com has more resources for developing with other datastores and might be a good resource. For DynamoDB's support for enabling mobile developers to build serverless architectures, please take a look:
http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/FGAC_DDB.html
Hope this helps.
Swami
If you have no clear idea about server side coding maybe you should use a backend-as-a-service platform such as Backbeam. These platforms give you SDKs for iOS and Android typically and you don't have to worry about the servers stuff. You can create a database in the control panel and start using it from your iOS apps making queries, inserting data, etc. You have also other features such as push notifications, users authentication, and more.
Disclaimer: I work at Backbeam. Other well-known platforms are parse and kinvey
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!
We're about to start a new project and I've been looking at some of the new web technologies. We want to build a RESTful api which a client can access. To date we've been using python with django/flask to build the api and using jquery for the front end.
I've read quite a bit on javascript frameworks such as emberjs and angular, as well as nodejs solutions like express, meteor and derby. I really like the idea that a site should 'auto update' when the model changes.I'm aware that there are some libraries like gevent which can help facilitate socket level communication, but it seems to be more of a patch than an elegant solution.
Ideally, I don't want to give up a proven technology, ie writing server code in python (or php,ruby whatever) for building my whole app on nodejs. Having a RESTful API is important since we want our services to be open and accessible.
Would it be a bad idea to have 2 servers and 1 client? 1 traditional api server communicating with a javascript framework on the client. Then also run a nodejs server alongside the api server which can somehow talk to the api and if it finds updates, passes it along to the client.
We want to build a RESTful api which a client can access.
Ideally, I don't want to give up a proven technology, ie writing server code in python (or php,ruby whatever) for building my whole app on nodejs.
Then you should probably go with Rails and Ember.js. I'll quote eviltrout (co-founder of discourse) which is build on ember and rails:
One amazing side effect of a rich client side app is you end up with a battle tested API. Our app has consumed our own API since day one, so we know it works.
If we want to create a native client for Android or iOS, it would be a lot easier because we already speak JSON fluently. If people want to build services that use Discourse, they won’t have to result to screen scraping. It’s a huge win for us and the developers that use our platform. 1
However you should keep in mind that ember is as of to date still a very young framework (rc3 v1.0.0).
I don't know what sort of application you are building (in respect to why you would want to use node) How to decide when to use Node.js?
I have recently found those two look-alike solutions/IDE for cross-mobile development: Appcelerator and Rhomobile (I know there are more) and I have questions regarding those two platform:
1) I believe the only way to build the view is using HTML, which I like alot the ideas. But, does that mean the application itself isn't available if the mobile is offline?
2) Do you guys know if it's possible to publish the application to the App Store and Google Store?
3) Are there any simulator for different mobile and do they support all those slide/tab events?
4) And finally, are there a way to transfert the App on your mobile phone without having to publish it anywhere.
Please note that I have no knowledge at all about mobile app dev and those two solutions (Appcelerator, Rhomobile) would be perfect for me as I am familiar with Javascript and HTML.
Thank you!
Ok I have only used appcelerator but:
1) a webview is like a browser without the address bar, it simply parses HTML, where it gets it from is up to you. If you write the HTML and pass in a file well then yes it can be offline, if it is used to parse a response from a webpage well then no as it needs to send a http request to the webpage.
As many people seem to mistake (for a reason unknown to me as all the documentation states other wise), appcelerator is not the same as phonegap, appcelerator uses its own javascript based API to allow developers to make native apps, it is NOT a webview wrapper. It is offline by default and allows you to send http requests if you need something online.
2) yes you can publish to the app store and the google store from appcelerator, the documentation walks you through the process.
3) Appcelerator requires you to download either the IOS sdk or Android SDK which come with simulators, appcelerator / the emulators support the standard events found on these devices.
4) With Android to can build a .apk file and distribute however you wish, with IOS the only way is to publish to the app store. the only other way is to make a mobile website instead of an application
I plan to make an online game. It will be a full real-time during play. For my website backend I have used Django. Database and other things are almost done. What is the best way to make user client side and server side backend for play in realtime? As I use Django it would be nice to have it in Python.
We plan that there will be minimum ~1000 online players all the time.
Twisted/Tornado/Node.js or maybe something else?
Thanks in advance.
Tornado is very light and pretty nice in my opinion. You could integrate it with Django in various ways -- e.g. Integrate Tornado in Django, Integrating Django with Tornado's web server -- or just run it alongside Django behind whatever web server you use.
Node is so fun that you might tire of Django. :-)
I think you should keep separately Django - which is used for general site functions, and Tornado - which is used for realtime data. I think you should use some Redis to store/read data and communicate between django and tornado, so prevent using database access directly from tornado.
Developing your own backend server sounds as interesting project.
But from my experience it becomes a very significant of your R&D effort.
It starts with developing core backend components, dealing with servers, installs, patches, security issues and more.
On top of it, you will need to create admin systems to manage your player, levels, xp, integration to stores and more... and then, you have the reports (installs, retention, etc'...)
I would strongly recommend using existing backend platforms.
I work at a company with a large SAP investment, and we also have dozens of large .Net systems (mostly internally for engineering systems), and Java platforms (mostly for external web applications). As such, we have large development shops on ABAP, C#, and Java EE.
We have decent standards for which platform to use in which domain, but we don't have a lot of clarity around when to use web UIs and when to use desktop UIs.
I've seen some excellent research on this topic in the past (like this), but I'd like something a little more structured
I'd like to build a decision tree based on best practices to help with this question.
Some of the criteria I've seen in the past include:
Is the application targeted to users
with different OS configurations?
Does the application require OS-type
functionality for sorting and editing
data? (I know that AJAX /
asynchronous JS has made possible
much richer desktop-like
functionality to web applications,
but some would argue the desktop is
still king in this area)
Will a web application be able to
provide the availability,
responsiveness, clarity, and utility
that can be delivered with a desktop
application?
I think we are seeing the separation between Web and desktop applications softened quite a bit. Rich internet applications (with Flex, Silverlight, Ajax) started this trend, and WPF with XBAP is taking the user experience of browser-based applications to another level.
It is becoming a bit more involved to have this argument, because there are now more flavors in the spectrum between Web and desktop apps.
Some more questions to ask:
What is the primary objective of the app - data manipulation, or data viewing?
What is the number of data points/records that need to be viewed/edited together on one screen?
What is the organization's IT infrastructure look like? Will they be able to accomodate new deployment models?
Will users work with a central database from remote locations?
Does the organization have a VPN infrastructure of off-site users, and how do users authenticate?
Are there existing applications that the same user group is working with, and how are these applications deployed?
Does the application need offline capabilities?
Given that they are so different, what is the skill set of the development team for web and desktop APIs?