User Experience (UX)
Business in the Front, Party in the Back (Office)

Summarized using AI

Business in the Front, Party in the Back (Office)

Kevin Whinnery • November 13, 2022 • Houston, TX

In the presentation titled "Business in the Front, Party in the Back (Office)" delivered by Kevin Whinnery at RubyConf 2022, the primary focus is on the significance and development of back office applications in software environments. The talk begins by differentiating between two types of applications: customer-facing applications and back office applications. The former typically receive greater attention and resources due to their direct impact on revenue, while the latter, which are crucial for internal processes, often suffer from underinvestment.

Key points discussed include:

- Dual Nature of Applications: The distinction between customer-facing and back office applications is crucial. Customer-facing apps prioritize user experience and UI polish due to their external impact, whereas back office applications focus on utilitarian functionality for internal users.

- Investment Challenges: Back office tools are often underfunded, primarily because they do not directly drive revenue despite their essential role in efficiency and operational success. This often leads to reliance on inefficient workarounds, like scripts and spreadsheets.

- Long-term Considerations: Developers are encouraged to think beyond the immediate needs of internal tools and consider long-term scalability, maintenance, and integration complexities.

- Retool as a Solution: The presentation highlights Retool as an effective platform for constructing internal applications swiftly and intuitively. Whinnery provides a demonstration of building a back office interface for a Ruby on Rails application using Postgres and API services.
- Demo Segment: In the live demonstration, he creates an administrative interface for managing blog posts and comments, implementing CRUD operations. He emphasizes the integration of rich functionalities using Retool, demonstrating how to link frontend UI components effectively with backend data sources.

- Final Thoughts: Whinnery concludes by reiterating the value of investing in internal tools and highlights the capabilities of Retool in bridging the gap between ease of use and powerful functionality, reinforcing operational efficiencies within organizations.

Overall, the session conveys the message that while customer-facing applications may capture the limelight, fostering robust internal applications is integral to organizational success and efficiency.

Business in the Front, Party in the Back (Office)
Kevin Whinnery • November 13, 2022 • Houston, TX

If you have ever built a web application, chances are that you have also had to deal with "the back office" - the chores and one-off tasks required to operate your software in production. Workflows that aren't user-facing, like creating promo codes, moderating content, or running reports, are often a janky combination of admin scripts and spreadsheets. Retool helps developers quickly and easily solve these problems with software instead. In this session, we'll show how to build a back office interface for a Ruby on Rails application using Postgres and several common API services, so you can keep your focus on the business in the front, and let Retool help throw the party in the back (office).

RubyConf 2022

00:00:00.000 Ready for takeoff.
00:00:17.720 All right, let's go ahead and kick things off. Folks straggling, that's totally fine. What's going on, everyone?
00:00:25.019 My name is Kevin Whinnery, and I'm the head of developer experience at a company called Retool. Today, I want to talk about a phenomenon in software development that isn't about the mullet you might think of when you read the title.
00:00:31.260 I want to discuss the two very separate types of applications that developers are responsible for maintaining. I'll touch on the relationship between customer-facing applications and back office applications.
00:00:38.340 Back office applications may serve a smaller audience but are no less impactful. I will compare these two types of applications and show you one approach to building the back office side using the Retool platform.
00:00:46.200 If you have any questions along the way, I'll try to save some time at the end to drill down into areas that might be interesting to you all. I wanted to start off by explaining a situation many of you have likely encountered in your software development career.
00:00:58.379 If you've got as much gray hair as I do, chances are you've found yourself in a situation where you've worked on a main application: the customer-facing experience that people associate with your software company.
00:01:11.580 In addition to that main application, there’s also the back office software—administrative interfaces and dashboards that run behind the scenes to help your business operate.
00:01:21.420 These are critical for production but often receive less prioritization. There are several properties that distinguish these two types of software.
00:01:31.260 Typically, the main application is what users interact with daily, so UI polish and a differentiated user experience become important for standing out in the marketplace.
00:01:41.220 In contrast, back office software is often internal-facing and is valued more for performance and utilitarian functionality rather than a super polished UX.
00:01:52.800 Consequently, these applications are frequently built for a small audience with very specific needs, such as your support team members, which leads to a different kind of development focus.
00:02:09.420 For instance, users may need to kick off long-running data export jobs or access sensitive data through a corporate single sign-on system. They require auditing due to regulatory concerns.
00:02:21.420 The requirements for these two types of applications can be quite different, and over the years, I've found that when there's a balance of both types, someone often loses out on prioritization.
00:02:30.240 Typically, it’s the back office applications that are underfunded or under-resourced because the main application drives revenue and is the focus of excitement for developers.
00:02:49.199 While building engaging software that impacts external customers can be more attractive to work on, the internal tools play a critical role that should not be overlooked.
00:03:02.040 One reason internal tools can get under-invested is that they primarily save time and improve efficiencies within teams rather than directly driving revenue.
00:03:18.900 However, this makes it hard to justify investments in truly great internal tooling, especially considering the impact often affects fewer people.
00:03:32.820 As a front-end developer, I appreciate the utility of internal tools but find making the same UI over and over again rather tedious. This is a significant factor in my current position at Retool.
00:03:50.940 Another disincentive to building internal tools is the maintenance burden that comes with yet another application in the stack. Many developers tend to think of these as quick CRUD applications.
00:04:06.240 However, creating and maintaining an application can lead to complexities you may not initially foresee. At Twilio, we had a philosophy of 'no free puppies.' This means you must consider the long-term scalability and maintainability of new technologies introduced into your ecosystem.
00:04:22.620 Internal tools are yet another area in which we might introduce additional complexity, such as older versions of dependencies that might hinder future development or cause security vulnerabilities.
00:04:42.240 Oftentimes, due to the lack of investment in infrastructure, we end up relying on workarounds that don't scale or are less efficient, like one-off scripts or tools running on developer’s laptops.
00:04:57.779 These may indeed accomplish specific tasks, but they create a fragmented workflow that can lead to inefficiencies.
00:05:06.900 For instance, you might encounter situations where business users need developers to run queries just to get the data they need. This adds additional overhead that shouldn't be necessary.
00:05:22.920 Most organizations find themselves in a situation where custom-built software could vastly improve workflows, providing better data integrity and reducing human error.
00:05:34.080 So, this leads to a desire for internal tools that allow teams to operate more efficiently and closely align with their work processes.
00:05:47.520 What I want to show in the back half of this talk is how to build out a back office side of an application using some tools available in the Retool platform.
00:06:00.600 Retool is designed for developers to create internal tools that drive business processes. For example, one of our customers, Stripe, uses it for their internal application that customer support uses daily to process chargebacks and refunds.
00:06:19.260 In your back office software, you’ll generally access the same data sources and APIs as your main application, but in a slightly different manner, likely with privileged access.
00:06:34.220 What’s more, you probably want to layer corporate SSO and audit logging on top of these privileged operations, which improves security and monitoring.
00:06:45.000 I’m going to show you how to connect your application layers’ APIs with a Postgres database to create an administrative interface.
00:07:02.000 So, let’s jump into the demo. I’ll demonstrate the hosted version of Retool, but note that you can also deploy Retool in your VPC using Docker.
00:07:11.640 Most internal applications start with access to various resources, like internal databases and APIs, which drive different parts of your business.
00:07:25.860 As an example, I’ll build an administrative interface for the Ruby on Rails guides blog, which includes posts and comments.
00:07:38.520 I’ll showcase how to perform CRUD operations and implement a human-in-the-loop workflow, where comments need approval before being published.
00:07:55.500 First, for the resource configuration, I have set up my Postgres database and ensure that I can access it.
00:08:06.840 Before we dive into creating, testing applications, let's ensure we can connect to both the database and the blog API.
00:08:17.700 I’ve already built and deployed my site using Render, which is a great replacement for the old free Heroku Dyno.
00:08:30.840 Now, I'm going to make sure that I can fetch data from the Postgres database associated with my render account.
00:08:43.740 After checking the status of my connection, I ensured that I can access the resources within my application to proceed.
00:08:57.560 Let's create a new application called 'Blog Admin' to manage blog posts and interactions.
00:09:12.840 On the canvas of this application, I will add components needed to display and manage blog content.
00:09:27.600 I will start with the necessary queries to pull the data for blog articles and comments and display them effectively.
00:09:43.320 Next, I will configure my queries by selecting the data source associated with my Rails application's Postgres database.
00:09:55.920 I'll implement SQL queries to retrieve articles from the database in reverse chronological order.
00:10:09.780 This will allow me to get the most recent articles quickly.
00:10:20.760 Let me execute this query to confirm the data retrieval is successful.
00:10:39.660 If the operation goes through smoothly, I will see a preview of the returned data.
00:10:57.060 Sometimes, network issues can hinder data retrieval, requiring troubleshooting.
00:11:15.060 Switching networks can often help improve connectivity to the database.
00:11:32.760 With a little luck and some adjustments, I'm able to pull in the fetched data for display.
00:11:44.940 Now that I have blog post titles showing up, it's time to continue crafting the user interface so that we can enact CRUD operations.
00:12:01.040 I'll set up the necessary components on the canvas to visualize articles and set functioning parameters.
00:12:16.140 The next step will include configuring the list to show each article's title and body, leveraging the dynamic capabilities within Retool.
00:12:32.580 As I drag in the components to build out the application, the process can feel intuitive, almost like assembling a puzzle.
00:12:49.800 For details about each article, I will need to ensure they display correctly, updating dynamically according to the fetched data.
00:13:04.540 Let's make sure to encapsulate the right functionalities for managing and moderating comments as they come in.
00:13:16.500 To promote efficiency, I'll consider additional functionalities that handle CRUD operations on blog posts.
00:13:25.320 Including input forms on the interface will allow users to create and update new blog posts seamlessly.
00:13:42.300 As I quick-create a form for new blog posts, I can specify inputs such as title, status, and body content.
00:14:09.860 Integrating rich text editing capabilities will allow users to craft content with formatting, enhancing the user experience.
00:14:27.300 Then, I’ll wire up a button to submit the new post, ensuring that the operation links back to the Postgres database.
00:14:44.620 When clicked, the submit button should perform a corresponding API request to create a new resource within the database.
00:15:02.840 To complete the interface, it's essential to ensure error handling is configured for any potential issues encountered during submission.
00:15:20.880 Let's finalize the form setup by adjusting the necessary parameters for validation, as it's crucial for ensuring data integrity.
00:15:39.900 I will introduce event handlers so that upon submission, data will conform to the established logic within the Rails application.
00:15:53.219 This approach mitigates the risks of direct SQL statement execution, ensuring that Rails validations are executed.
00:16:08.880 Now, let me gather the titles and bodies from the input fields to push the new posts to the Rails API.
00:16:26.340 The structure of generated requests will align perfectly with the Rails naming conventions for each field needed.
00:16:55.380 Once everything is in place, I'll ensure seamless communication between the user interface and the backend.
00:17:11.220 Now it’s time to test whether the functionality works as expected by attempting to create a new blog post.
00:17:26.640 Upon successfully adding a new post, the system should respond by re-fetching and displaying the latest articles.
00:17:44.040 While testing this, I received an error, which suggests some troubleshooting may be necessary to address potential hiccups.
00:18:02.880 Through trial and error, we can identify issues within the backend or configuration that may be affecting the API calls.
00:18:23.640 After some debugging, the submission of the new blog post finally succeeds, which is a relief as it allows the flow to continue.
00:18:42.720 In summary, in just a short period, I’ve demonstrated how to implement CRUD operations efficiently using Retool.
00:19:01.860 Retool seamlessly supports integrations with corporate SSO and with built-in audit logging to maintain operational efficiency.
00:19:17.640 Furthermore, we introduced the essential framework for building robust internal tools and discussed the opportunities ahead.
00:19:32.520 Retool allows developers to create internal platforms driven by data with ease, ultimately maximizing operational capabilities.
00:19:47.640 If you have any questions about Retool, feel free to stop by my table in the exhibit hall for further discussions.
00:19:58.680 Also, I have Lego sets to give away! If you sign up for a Retool account and build something quickly, you might win one.
Explore all talks recorded at RubyConf 2022
+62