The year was 2015 and my feature team was forced to learn Salesforce. I know that sounds extreme, but that was the reality for the six core members of our team who were required to adopt the force.com platform as a part of a corporate objective. Other than an introductory session from Salesforce during the 2008 Gartner Application Architecture and Design conference, I really had no depth of knowledge for a CRM product which promised a "No Software" implementation. However, I did receive a pretty nice T-shirt for attending the session. A Fast Journey The goal of the 2015 initiative was two-fold: get the team up to speed with the Salesforce ecosystem convert an existing CRM solution to Salesforce The six-person team consisted of four full-stack developers and two quality assurance team members. Prior to this assignment, our project sprints had been focused on using leading-edge, open-source frameworks and technologies. As one might expect, getting to know Salesforce in the pre-lightning era seemed like it might be a step back because we all felt like we were working on an assignment that lived within a closed-source proprietary system, or what is often referred to as a "walled garden". : a software system wherein the carrier or service provider has control over applications, content, and media, and restricts convenient access to non-approved applicants or content. This is in contrast to an open platform, wherein consumers generally have unrestricted access to applications and content. Walled Garden When talking about the project, at the time, my biggest hesitations with the Salesforce solution were the following: non-standard options for client customization inability to work in a git-based workflow inefficient request/response pattern for client/server communication inability to end-to-end (E2E) test Salesforce customer solutions Our implementation went live in November 2015. In fact, the project was considered the most-successful software implementation for my employer – which was delivered without any delays or compromise in functionality. Since it has been five years, I thought it would be appropriate to see how Salesforce has changed. After all, five years is considered an eternity in software design and architecture. A New and Open Course When I speak with team members in the Salesforce/MuleSoft practice at , they only nod in agreement when I recall the project which consumed about 50% of my employment in 2015. In every case, these technologists are eager to point out just how far Salesforce has evolved from being a walled garden. One key indicator to determine this is to check for the presence of open-source projects. Without much effort, I was able to locate the official Salesforce page on : CleanSlate Technology Group GitHub At the time this article was drafted, there were 211 repositories which I had access to view using my GitHub account. The next step is to understand how many of these repositories make the Salesforce experience more open sourced and break down the walls of a closed-source ecosystem. Sorting the repositories by the highest star rating to the lowest star rating, I found some very exciting and active projects—some of which publicly expose functionality internal to the Salesforce CRM solution. Client Improvements One of the biggest challenges of the Classic version of Salesforce was the lack of a rich-text client which could be extended. During my 2015 project, I remember our team included a compressed archive of JavaScript libraries to provide a user experience which was more in line with customer expectations. The Lightning upgrade with Salesforce introduced the (LCF) and a model which is called "Aura." The LCF upgrade solved a number of challenges, but still maintained some degree of proprietary design – until the following open-source projects were initiated: Lightning Component Framework : contains the source code for the Lightning Web Components Engine and Compiler lwc : -based implementation of the Salesforce Lightning Design System design-system-react React : provide the source code for the base components of the Salesforce Component library base-components-recipes Open sourcing the code related to the client-side of Salesforce communicates a zero-transparency message and allows those working in the Salesforce ecosystem to gain a better understanding of the underlying code driving the client experience. Additionally, feature teams interested in leveraging React no longer have to dive deep into the Aura model. But Wait ... There's More By open sourcing the repositories noted above, the following challenges from my 2015 implementation are no longer an issue: non-standard options for client customization inefficient request/response pattern for client/server communication The two remaining issues have also been addressed: inability to work in a git-based workflow is met with Salesforce DX inability to end-to-end (E2E) test Salesforce customer solutions is now possible with TestimSalesforce DX provides an integrated, end-to-end lifecycle designed for high-performance agile development. The lifecycle is open and flexible, facilitating integration with common and preferred tooling for building applications. By contrast, I have published the following articles on DZone in 2017 to demonstrate the steps required to automate the build process with Salesforce: Salesforce DX Continuous Integration With Salesforce Configuring Stash/Git for Salesforce With the Force IDE For Eclipse Deploying Salesforce Using Bamboo The Salesforce DX product eliminates a majority of the manually driven tasks, while introducing automation to create Scratch orgs which can be used to validate git-based updates. Once validated the Salesforce updates can be migrated using standardized deployment solutions. E2E Testing Using Testim While use of is possible with Salesforce for end-to-end tests, the product has gained approval by the Salesforce QA engineering team from an E2E perspective: Selenium Testim Automating Complex End-to-End Tests Use of the Testim product enables the confident execution of complex E2E tests, replacing the requirement of manually-executed tasks. With a stable E2E solution, QA engineers can finally embrace exploratory testing to potentially uncover bugs from alternate flows which had not been fully validated due to time and resources. Feature teams working on Salesforce-related functionality can add Testim to their development lifecycle toolset to perform the same degree of E2E testing prior to releasing new features and functionality. Conclusion At the end of 2015, the Salesforce ecosystem was a walled garden. While my feature team was successful at deploying a solution that end users loved and appreciated, the feeling of deploying a "closed" solution was bittersweet from a technology point-of-view. The current state of Salesforce reflects a great advancement from an open source perspective. In fact, a great deal of time and dedication has been allocated to support and maintain the client-related repositories noted above. Furthermore, the Salesforce DX product allows feature teams to adopt git-based workflows as a part of their development lifecycles. From an end-to-end perspective, the use of Testim handles the complexities related to complex and long-running scenarios which should be validated before the functionality is made available for customers. Salesforce provides a summary of additional open-source projects that can be tracked at the site: Salesforce Open Source This site provides another view into the mindset of the Salesforce engineering team, offering open-source contributions to concepts which do not map to CRM-related opportunities to solve. Some interesting items to consider are noted below: : a flexible, modular, and composable framework to model socio-economic behaviors and dynamics with both agents and governments AI Economist : state Management Tailored-Made for JS Applications Akita : AutoML library written in Scala that runs on top of Apache Spark TransmogrifAI : IAM Least Privilege Policy Generator. Policy Sentry Clearly, Salesforce is no longer a walled garden. Have a really great day!

Apache

Salesforce

Sentry

How To Make a Twitter Graph with Slash GraphQL

How To Connect Heroku Server with Slack

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

Too Long; Didn't Read

Salesforce: Walled Garden No More

Salesforce: Walled Garden No More

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

5 Signs You’ve Built a Secretly Bad Architecture (And How to Fix It)

Top 10 Development Frameworks in 2020

4 Tips for Building the Ultimate Finance App

6 Reasons for Using Bootstrap Framework

6 Reasons Why No-Code Platforms are the Future Of Software Development

65 Stories To Learn About Framework

5 Signs You’ve Built a Secretly Bad Architecture (And How to Fix It)

Top 10 Development Frameworks in 2020

4 Tips for Building the Ultimate Finance App

6 Reasons for Using Bootstrap Framework

6 Reasons Why No-Code Platforms are the Future Of Software Development

65 Stories To Learn About Framework

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps