Download to read offline
Uploaded byIgor Androsov
Igor Androsov on Mobilizing Salesforce Data with 12 Factor App on Heroku
The document outlines best practices for building cloud applications using the twelve-factor app methodology on the Heroku platform. It discusses the importance of factors such as codebase management, dependency declaration, and statelessness in app design, while also addressing risks related to forward-looking statements about Salesforce's services. Additionally, it provides references to tools and resources for API design, mobile app development, and deployment processes.
More Related Content
Similar to Igor Androsov on Mobilizing Salesforce Data with 12 Factor App on Heroku
Igor Androsov on Mobilizing Salesforce Data with 12 Factor App on Heroku
- 1. Igor Androsov Cloud Architect igor-androsov@bisk.com @iandrosov MobilizeSalesforce Data Using Twelve-Factor Apps on Heroku Best practices for building modern cloud applications
- 2. Forward-Looking Statements Statement underthe Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services. The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site. Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.
- 3. How to turnyour ideas, wireframes, and designs to functional production app – Product Engineer Build Me a Mobile App It is Simple right?
- 4. Twelve-Factor App methodology helpsProduct Engineer/s Ideas & Concepts to App Twelve-Factor Journey to the AppStore
- 5. Tools Heroku, Postgres, Heroku Connect Swagger,Node.js, ES6/JavaScript iOS mobile app built with Swift 3, Xcode 8 Salesforce, Force.com, APEX, AppCloud, Lightning Platforms, Frameworks & Languages
- 6. API Design &Documentation – Swagger Demo Setup With API current documentation is key Design API with Extensible grammar YAML, JSON or RAML enables rapid iteration, validation & testability. Swagger, Apiary, Apigee, tools to design API Modern cloud apps are API first
- 7. Enter Twelve-Factors Codebase 1 2 3 4 5 PortBinding 7 Dependencies Configuration Backing Services Build, Release & Run ProcessConcurrency 6 Disposability 8 9 10 11 12Admin Processes Logs Dev, Prod Parity
- 8. 1. Codebase Git, GitHub,SVN etc. Code base in single repository App is single codebase Many apps should not share same code base Create shared Libraries & Frameworks One codebase tracked in revision control, many deploys
- 9. 2. Dependencies Explicitly declareand isolate dependencies Automate dependencies with tools & package managers Use package manager when available, (most modern runtimes have PM) Node.js & JS – NPM Xcode - cocoapods
- 10. 3. Configuration Configuration, isanything that vary between environments. DB Connections, credentials, etc. Code Does Not! Heroku – environment variables Xcode – build targets & plist Store configuration in the environment
- 11. 4. Backing Services Defineyour dependencies cleanly gives system flexibility Each part in a system abstracted from complexity of another …good architecture Heroku – AWS S3, DB, Salesforce etc. Mobile – REST APIs & services Treat Backing Service as attached resources referenced by endpoint or URL
- 12. 5. Build, Release& Run Follow your chosen framework build process Strictly Separate Build & Run Stages
- 13. 6. Process As appscales it may run on many servers That code should run stateless State is important to business - keep the state in an external reliable store. Heroku Dynos – isolated, lightweight, share nothing, Linux containers Execute App as One or More Stateless Processes
- 14. 7. Port Binding Web-appservice typically exposed over HTTP on some port Node.js Express framework & Swagger runtime port binding Export Services via port binding
- 15. 8. Concurrency Run yourcode as lots of small processes. Node has limited scaling ability due to single threaded nature Node.js must fork processes – “clustering” Scale out via process model
- 16. Enable Concurrency inyour app - Demo Node.js clustering with Throng
- 17. 9. Disposability Maximize robustnesswith fast startup and graceful shutdown New versions of your app should launch quick and start handling traffic. Apps must handle interruptions or shutdown requests gracefully.
- 18. 10. Development, ProductionParity Very simple with Heroku Pipeline Automated deployments CI Pipeline Promotion* Keep development, staging and production as similar as possible
- 19. 11. Logs Monitor Logs Listento log events & errors Filter events and actions Treat Logs as event stream
- 20. 12. Admin Processes Consoleis critical administrative and debugging tool Heroku Toolbelt provides command line administration Can be scripted & automated Run admin/management tasks as one-off processes
- 21. Real data, realfast with Heroku Connect. It is NOT ETL, rather data synchronization tool for Salesforce data & Postgres Database Synchronize Real Data – Demo Heroku Connect
- 22. Summary What did wejust do?
- 23. Architecture Anatomy Demo appanatomy in Twelve-Factors API Limit, License
- 24. Resources Heroku Dev Center- https://devcenter.heroku.com • Heroku Postgres - https://www.heroku.com/postgres • Heroku Connect - https://www.heroku.com/connect • Papertail - https://elements.heroku.com/addons/papertrail Node.js - https://nodejs.org • NPM - https://www.npmjs.com • Swagger - http://swagger.io Swift - https://swift.org • XCode - https://developer.apple.com/xcode/ide/ • Cocoapods - https://cocoapods.org Github repository - https://github.com/iandrosov/df16-harvest-api Twitter: @iandrosov
- 25.
Editor's Notes
- #2 At BISK we believe in innovative online learning solutions to elevate the lives of people all over the world.
- #3 Key Takeaway: We are a publicly traded company. Please make your buying decisions only on the products commercially available from Salesforce. Talk Track: Before I begin, just a quick note that when considering future developments, whether by us or with any other solution provider, you should always base your purchasing decisions on what is currently available.
- #4 Story on building an app. How to turn concepts, designs, agile stories and great ideas into production app? To help bridge that gap of loose agile stories we need that allusive skill of a Product Engineer – somebody with skills of a coder who can also translate endless requirement streams into meaningful information that can be understood by other developers who will collaborate and help build our app.
- #5 For better collaboration with globally distributed developers for this app we will see how to apply 12-factor app methodology with several techniques specific to platform and developer tools on this project. Swagger live API documentation, Xcode storyboard references enabled us to split screens into functional areas that can be coded independently and then merged into main code base without major conflicts on common files. Using git-flow with feature branches to manage updates to requirements and additional features paired with Heroku Review apps in pipeline. Twelve-Factor App - best practices for building modern cloud applications published by Heroku co-founder Adam Wiggins. https://12factor.net/
- #6 Introducing developer toolbox, Salesforce platform, Heroku platform with addon services, Heroku Postgres DB & Heroku Connect, Node.js & Swagger, Xcode & Swift – new programming language introduced by Apple 3 years ago and now on release version 3.
- #7 Choosing common language across engineering, UI/UX to Mobile to Server developers. Common API language definition YAML or RAML enables real-time design and test iteration of live API with live documentation. With Tools such as Swagger, Apiary, Apigility and others it made possible. Deploy code often, possibly new features every day to production. http://raml.org/ Heroku Pipeline + github enables you to test & deploy features without impact *Mobile apps are installed on devices and updates are more difficult to adopt this be more exception
- #8 Twelve-Factor infographic
- #9 Shows github repository and CI integration with Heroku for automated deployments.
- #10 NPM manage dependencies for Node.js and Javascript aps Live demo may be possible (as network allows this takes some time) Use existing packages to run demo.
- #11 Twelve-Factor infographic
- #12 Shows how Heroku Manages ENVIRONMENT variables for different environments Dev, Stage, Prod. All configuration data should be stored separate from the code.
- #13 Shows by example several backing services, Postgres, Papertrail, Connect/Salesforce.
- #14 Demo live Heroku deployment if possible, update repository and push code via CI
- #15 Show Dynos scalable procs Important: Stateless app more robust, and easier to manage, generally incurs fewer bugs, and scales better.
- #16 Show where Port binding setup in Swagger generated code related to node.js and Express
- #17 Node has limited scaling due to single threaded nature and V8’s memory limit, cannot use additional CPU cores. To scale on multicore CPU or dynos Node.js must fork processes – concept called “clustering” support by standard API in Node. Heroku buildpack provides defaults through two environment variables: WEB_MEMORY and WEB_CONCURRENCY. Node app must be enabled for concurrency using Cluster API or in this case we use Throng - one of API abstraction packages for Node. With Cluster, you can optimize your app’s performance across various dyno types. Recommendation for all apps to support clustering even if app intended to run a single process. ** Clustering available for paid Heroku accounts with Free, Hobby or full standard 1x or more dynos. This code example will be limited to 1 worker process on the Free & Hobby Heroku dynos.
- #18 1. determine how many processes we should cluster: 1 default 2. define a start function that will be the entry point for each newly clustered process: 3. use throng to cluster the app into multiple processes. We specify a lifetime of Infinity to tell throng that, if a worker dies, it should be respawned - so we will always have WORKERS processes running Example: https://github.com/heroku-examples/node-concurrency/blob/master/server.js
- #19 Demo scale down dynos dispose services Deploy code often. Heroku Pipeline + github enables you to test & deploy features without impact *Mobile apps are installed on devices and updates are more difficult to deploy
- #20 Demo Pipeline feature aligned with environment parity. For other types of development can use tools like Vegrant to keep these environment dev copy.
- #21 Show examples of papertrail logs and also log via toolbelt Some of Heroku addons - Papertrail & Logsview can monitor log events send alerts on that stream. *Mobile App crash-logs can be sent as reports to developers via Testflight or MDM distribution systems.
- #22 Show toolbelt CLI as example of admin tool This mostly relevant on server side Using CLI tool for administration enables system automation with scripting administrative activity to run automated.
- #23 We have a working prototype of the app but it is not done yet. We are missing real data! Using Heroku Connect is really easy and fast to sync data between Salesforce and our Postgres DB to drive our mobile REST API. As we map Salesforce objects, Heroku Connect will create Postgres Tables and columns for this app and start data synchronization. Data can be moved bidirectional to/from DB to/SF. Heroku connect is a product that counts records under management in license capacity. After mapping and sync is complete we can try to demo our mobile app with display of real data. **Add new logic with DB fields, map data on Heroku connect and update the services logic.
- #25 Discuss the Heroku-Synchronization Architecture pattern and compare it to direct connected mobile apps to Salesforce built with SDK. Discuss API limits and licensing factors when connecting direct from mobile app to SF such as S1 app vs. more scaled public access with Heroku hosted API and
- #26 Useful resources list
- #27 Useful resources list