I am still discovering awsmobile and still have to read a lot of doc but what I don't really understand is why awsmobile init generates a awsmobilejs/backend in my React project because:
1) I think FE and BE should NOT be in the same repo.
2) I'll probably be creating mobile apps later, also in separate repos. How will it work then? According to doc I have to run awsmobile init <project_id> again which will download the awsmobilejs/backend folder there too (duplicate)
It makes sense for me to separate FE and BE, especially if you have several front ends (WEB, and mobile apps).
Aws mobile hub even lets you create several "apps" in the console (android, iOS, web and react-native).
How do I separate everything? and "connect" them later?
Bonus question:
How does awsmobile (cloud-api) differ from aws SAM
They seem to achieve similar things for the Backend
Thank you
Enabling developers to develop frontend and backend in the same project was actually one of the design goals of the awsmobile-cli. We thought it would make development easier.
And one BE project can be linked to multiple frontend project using awsmobile init <project-id>, as pointed out in 2).
I don't see any issues with this setup, but arguments against this design are welcome, and will be taken into consideration in our future updates.
It'd be more helpful if you describe some scenarios in details that this design leads to bad project development life cycle managements.
Related
I and a friend want to work on same project but we are in different location.
I will be working on backend while he will be working on frontend.
How do I feed him with my backend API. What's the best solution, app or tools to use.
Strongly recommend using git as a collaboration/version control tool. You can sign up for free at github.com and they now support private repositories. There's a bit of a learning curve, but git is highly adopted and one of the standards for managing code between several 100s or even 1000s of contributors across large projects.
Some of the basics:
1) think of git as a way to share code between developers
2) not only that, but you can manage change history and track changes over time
3) seamlessly manages most changes, enabling you and your team to view point-in-time versions
Check out the Git handbook at https://guides.github.com/introduction/git-handbook/ to get started!
To address your specific question:
when you are ready to share your backend code, check it into your git repository and let your collaborators know that updates are available
make sure to include instructions on how to use your backend code; do they run the server locally? is it deployed to a url? is it running in docker or kubernetes? is it authenticated, and how?
they will "pull" your changes and start working against them; when they have updates, they should commit them to git and push to the remote repository. You can then pull down their changes and review the full frontend/backend solution.
You can use these tools to make your life easier
Github or Bitbucket for code collaboration
Postman or Postwoman for API share
Jira cloud or clubhouse for Issue tracking ( free for 10 users)
Confluence for documentation.
Slack for real time communication.
These are tools I am using for collaboration with others. This is just my opinion.
I am looking for the list of blockchain projects which are implemented in mobile apps natively. If you can find some, please point me to the list. If not, please let me know why there are no much blockchain projects implemented in mobile natively. Could it be due to performance, gas cost, complexity etc?
There are many risks that you as mobile app developer need to take care of when you ship your DApp in a form of mobile application.
1: Security - building your own app for blockchain means you have to built key management by yourself.
In current state of DApp, we have MetaMask, Cipher browser, Status browser, Trust browser and many others. The main problem that they're trying to solve is account management, the private key management, recovery process & good UX.
All of these need to be taken care of by yourself if you want allow your users to sign up for an account aka creating private key and store it securely in the phone. If hackers managed to reverse engineer and exploit your mobile app, they will be able to crack down the private key vault (the place where you store the private keys for your customers in their phones). You are screwed.
MetaMask and the gang above have experts that know what they are doing and always put security as their main pillar in the engineering process. Apart from that, they also have design team that always come out with better UX ideas so that everyone can adopt blockchain easily.
Bottom line, if you have security and design experties in your team that know well how to handle the key management, recovery process (mnemonic/seed phrases) & etc, it's probably a good idea to build your own inside your mobile app. Otherwise, I strongly recommend you just build web DApps and leverage MetaMask or DApp browsers above.
2: Trust - the idea of blockchain itself it to make everything decentralize and transparent. When you build a mobile app for your DApp, means you making it centralize. Your solution lives somewhere, in a server.
You will be relying on Apple and Google everytime you want to push app updates. Imagine you are an iOS developer and Apple is taking very long time to review and approve your app update submission? There's nothing much you can do because you are in centralized/close loop environment.
If you make it as web based DApp, you can deploy your DApp updates at any time you want. In addition to that, you also can host it to IPFS or Swarm to make it really decentralized application.
The beauty of not making it as a mobile app here is, your users can browse the code because all they have in their browser are static files; HTML, CSS and JS. Your users can tell if you are doing something bad in your code. Because they can right click on your web DApp and see the page source.
But if you are doing this as mobile app, your users can't really know what is 'behind' the app and you will find hard times to convince them later that they are in a good company.
3: Development - Web3JS is the most popular and stable project right now. It acts like a bridge layer between your DApp UI and the blockchain. And of course, it's written and needs to be implemented in JS.
Even now we started to see Web3 has been ported out to many other flavors i.e. for Swift and Kotlin, they are still new. Means, you will spend a lot of man hours later trying to debug and solve issues that only less people know to help/fix it.
To share my experience, I'm a Rubyist and there are some Web3 flavors for Ruby now. But, from what I've tested, they are still far from perfect and stable and at last, I decided to port everything to Web3JS for front-end components and Go for back-end. components.
FYI, the Ethereum Geth client is written in Go, check-out go-ethereum project. That means, everything that you need to do later i.e. creating transaction, signing transaction, querying blocks/transactions, creating/retrieving private key & etc has been tested and being used in real production. At any time when you are stuck, you can go ahead, read the source code of go-ethereum to learn how they do specific thing (the list above).
I'm not going againts all these new flavors. What I'm trying to tell you here is, it's going to take time for all this new flavors to get matured and stable enough. My advice for you now, if you want to do DApp, use Web3JS. If you need some back-end work (your centralized server <> blockchain), use Go.
I hope this helps!
I know that all these components exist, however I really am trying to figure out if someone has brought all these together.
Here is what I need:
JavaScript/NodeJS core application boilerplate/framework
With a website, HTML app (aka PhoneGap or even better Ionic), and ideally option to add something like a desktop app (like electron) client flexibility
All with possibility of different/specialized frontend code so all assets and HTML could be packaged into the app
Ideally kept in one GIT repo
With shared code amongst all UIs
Ability to use Angular 2 in all environments (or something similar)
Realtime? standardized data connection with data source (like meteor's DDP), I really dislike polling and I don't want to have to write my own data protocol
Have some kind of authentication capacity
Already exist in some way
What I have been eyeballing thus far is Ionic2 on top of Meteor, however it is remarkably difficult to find an actually working example of them playing together and I have not found any with separate codebases between the two interfaces.
To clarify, below is sort-of what I envision for a folder structure:
public/
common/
models/
business-logic/
server/
web/
desktop/
mobile/
And in that, all UIs and server can import from the common folder.
The end goal is to have something like Slack where they have 3 different ways of accessing the same data using the same rules but can really specialize in each interface type.
Does this exist?
I am really looking to have something that can be started with:
git clone http://github.com/a/bc
npm install
# do some other things that are documented
meteor run ios
Or am I not gonna have my cake and be able to eat it too?
I know I am shooting for the moon, but I know I can't be the first person looking to do this
For the backend I think that LoopBack may be a good bet if you want fast developement.
They have some examples for iOS, Android and Angular apps on their website:
You may get some ideas from their documentation or several example projects on GitHub.
LoopBack is currently backed by IBM.
Is there a good solution for A|B Testing in mobile apps like online? I know with iOS it's against the TOS to have different user experiences with identical actions, but what about Android? And what about firms like Apsalar which claim to offer A|B Testing in their analytics for apps? How would one implement that?
Artisan mobile makes an A/B testing solution for iOS and Android.
The basic idea is that you drop the SDK in your app and then put it out in the app store. You can use the service to create A/B tests and optimize your application without having to touch the code or go back through the app store for each test.
For mobile apps, A/B testing basically works by replacing static, hard-coded objects with dynamic objects that can be controlled from a remote server.
This methodology raises a potential performance issue: What if the end user's device is not connected to pull configuration data for an object being tested? We've built Splitforce (http://splitforce.com) to seamlessly setup and manage A/B testing in mobile apps while controlling for performance risk.
Los details
Once the SDK and experiment has been integrated, non-technical product or marketing folks can setup new tests or tweak existing tests on-the-fly - without having to resubmit to the app stores or hassle engineers.
On first app launch, the mobile app requests configuration data from the server and then caches that data locally on the device. This is to both ensure a consistent user experience on subsequent app launches, and prevent corrupt test results by guaranteeing accurate attribution of conversion events to variations.
If the end user's connection fails or is timed-out on first app launch, the library displays a hard-coded 'default' variation. And to make sure that everything is looking good before you go live, we've built a 'shake to preview' functionality in debug mode that does just that :-)
Once the app is deployed with Splitforce event data are stored locally and sent back to the website to be displayed for each variation alongside measurements of observed improvement and statistical confidence.
Instructions on integration of the SDKs and new tests can be found at https://splitforce.com/documentation.
And how is it used?
We've seen Splitforce used to A/B test:
UI elements + layouts (color, text, images, ad/menu placements)
UX workflows
Game dynamics + rules
Prices + promotions
We've also seen the tool used to control mobile apps remotely, by essentially setting one variation of a test subject to 100%.
Yes there is: E.g. the company Leanplum offers a Visual Interface Editor for iOS and Android: This requires no coding, and Leanplum will automatically detect the elements and allow you to change them. No engineers or app store resubmissions required.
Apple must have updated their TOS (https://developer.apple.com/app-store/review/guidelines/#user-interface) - At least I am not aware of anything that prohibits altering the UI in a way that the Leanplum Visual Editor is doing it.
Generally that is achieved by method swizzling (iOS) and reflection (Android).
To learn more about the Leanplum Visual Interface Editor, check out leanplum.com. They offer a free 30-day trial.
(Disclaimer: I am an Engineer at Leanplum.)
I wrote a small open source project called Switchboard.
It let's you A/B test, remote configure and stage rollout things in your native mobile app. It contains a server component that specifies what information the application should have and 2 native clients for android and iOS.
You can find the codebase at github.com/keepsafe/switchboard and a blog post about how you can use it HERE
The new kid around the block is Arise.io. They provide an A/B testing service for iOS and Android.
I wrote MSActiveConfig, an extremely flexible framework to do remote configuration + A/B testing on iOS, with a portable format to be able to implement clients on other platforms: https://github.com/mindsnacks/MSActiveConfig.
This framework is being used in applications with more than 5 million users.
There have been a spate of new entrants in this field...you could check out Swerve, Appiterate, leanplum...all of them seem to be having SDKs for iOS as well, not really sure whether and how Apple TOS allows for that, but since there are some many of them doing it, there must be a way.
Yes, new entrants are showing up in app A/B testing practically every week! But, I think Appiterate has gone two steps ahead of other competitors by creating a visual interface, without any need to re-write code. I have seen their platform (you can ask for an invite. I got a demo within 12 hours) and believe me, it is actual WYSIWYG that they are providing.
So, yes, this is probably 1000th question on the subject. However, my question is somewhat different from others that were asked about this, so please bear with me:
I am looking to develop a single mobile-app that targets the three/four popular and/or growing mobile platforms (Iphone, Android, WinPhone7, RIM). This application is an extension of an existing SaaS system that my startup currently offers. This mobile-app would provide a quick-and-simple way to view up-to-date status & chart & report information for the data that SaaS application collects. Connection to the internet is required 100%. No data entry besides username/password. App is very simple with 5-6 "pages".
In phase 1, all that would need to be supported is for user to log in, get to see current status of his data stored in the cloud, get access to a few live reports
In phase 2, I'd like to be able to offer push-notification of certain key events from my servers in the cloud
My goals are:
1) The back-end processing that generates data for reports is already written in ASP.NET MVC2. I want to re-use it. It can be exposed as either a WCF service or published on a mobile-friendly website
2) I'd like to be able to deploy the patches faster than through the official app-stores/marketplaces.
3) I cannot afford to spend a lot of resources to target three-four proprietary platforms, for an app that is auxiliary to the vertical purpose of the business. I want to develop it once for all 3-4 platforms.
4) I do not have access, nor do I want to purchase a Macbook
5) I do want to deploy thru the vendor-specific application marketplaces
6) I'd like to stay way from proprietary languages/frameworks/lock-ins
Sounds like what I need is a shell around a mobile-friendly site that can be packaged as an app. Are there existing products that can make it REAL EASY for me to do so? Will doing so, preclude me from doing push notifications in phase 2?
Can anyone recommend a "shell" product that would make a wrapper around the website as well as Javascript library that would look the best across all 4 platforms. I've seen the names like Jqtouch, Jquery Mobile, etc... but not sure which ones are better for what I need.
Do I need PhoneGap? I am not 100% sure here. Can PhoneGap use online-only html/javascript pages to translate into native code or must html/javascript files be distributed with the application? I'd rather have the website itself drive the UI completely, as I can keep changing the website without various version approval processes from vendor market-stores.
Thank you for help
I don’t think you need Phonegap after reading about your project goals. You might consider a Web App instead of a native one if you 1) dont want to buy a mac (required for iOS even tho you can compile it in the cloud: https://build.phonegap.com/), and 2) want to apply and deploy updates anytime without going thru those platform independent marketplaces and approval processes.
jQuery Mobile would be an excellent choice, currently (at this very moment) in Alpha 3 but a very stable one and you can deploy your system on any of those platforms. Note that if you focus your efforts in a Web App you can’t target the second phase you mentioned: Push Notifications.
If you decide going Native, then Push Notifications services can be deployed into your Phonegap project once you setup the proper web services and certificates (take a look # http://easyapns.com);
..and one quick note, the idea of phonegap is that all resources (html, js, images. etc) have to be distributed locally within the app and then getting online data (like reports, etc) using JSON from another web service, and that’s another easy task to accomplish. Phonegap DOES NOT compile your HTML files into native code (ObjectiveC or Java), it just load your Web App into a UIWebKit component at run time (in the case of an iOS app)
Another alternative could be using Titanium - http://www.appcelerator.com but this approach is more javascript oriented and your final app looks much more native. (not HTMLs here so I think thats a drawback for you)
Hope it helps :)