Sam Selikoff — Podcast Appearances & Summaries

Featured On 1 Podcast

Full Stack Radio

3 episodes

All Appearances

3 episodes

106: Sam Selikoff - Single Page Application Architecture

Full Stack Radio

Jan 16, 201955 minGuest/Developer

AI Summary

→ WHAT IT COVERS Sam Selikoff explains how to architect single-page applications by treating them as desktop apps that happen to run in browsers, focusing on client-side data management and keeping backend APIs minimal. → KEY INSIGHTS - **Client-side data normalization:** Build an identity map that stores normalized data locally, rendering all UI from this cache rather than individual API responses. This prevents duplicate data and keeps UI synchronized across components automatically. - **Optimistic UI patterns:** Create records in the local data store immediately without waiting for server confirmation, displaying them at 50% opacity or similar states until persisted. Handle the 0.1% failure cases separately rather than making users wait every time. - **Offline-first architecture:** Queue network requests in local storage or IndexedDB when offline, allowing users to continue working. Sync queued operations when connectivity returns, treating the client cache as source of truth that eventually syncs with server. - **Desktop app mental model:** Think of SPAs as native applications using the browser as runtime, not websites. This shifts complexity from maintaining two codebases to building one rich client with a commoditized backend API layer handling only data persistence. → NOTABLE MOMENT Selikoff describes using Mirage to build entire features and write tests against simulated server states without touching the network, defining what the backend needs to change before writing any API code, reducing backend work to 5% of development effort. 💼 SPONSORS [{"name": "Cloudinary", "url": "https://cloudinary.com"}, {"name": "Rollbar", "url": "https://rollbar.com/fullstackradio"}] 🏷️ Single Page Applications, Ember.js, Client-side Architecture, Offline-first Development

Read Full Summary Listen

107: Sam Selikoff - Pushing Complexity to the Client-Side

Full Stack Radio

Jan 30, 201950 min

AI Summary

→ WHAT IT COVERS Sam Selikoff explains how to build client-side applications using Ember and Rails APIs, focusing on keeping server code simple by pushing complexity to the client through JSON API conventions and declarative resource definitions. → KEY INSIGHTS - **JSON API Resources gem:** Eliminates controller code by declaratively defining resources in Rails that automatically handle CRUD operations, routing, and model mapping. Developers specify relationships and attributes, letting the gem generate standard endpoints without writing custom controller logic. - **Client-driven validation strategy:** Implement duplicate validations on client and server, using client-side checks for immediate feedback and server validations as the canonical guard. For uniqueness checks, query the API for existing records rather than creating custom validation endpoints, keeping the server dumb. - **Direct S3 uploads pattern:** Request signatures from the server as a resource, upload files directly to S3 from the client with that signature, then update the model with the returned URL. This eliminates server bandwidth doubling and enables rich upload experiences with progress bars. - **Escape hatches for custom logic:** Use before_save and after_save hooks on resources or drop into custom controllers when needed for operations like Stripe payments or email notifications. Ninety percent of code remains declarative CRUD operations, with custom logic only where absolutely necessary. → NOTABLE MOMENT Selikoff describes building a real-time conference app using Firebase and Ember where creating models in the Firebase console instantly updated the Ember application in another browser without any custom synchronization code, demonstrating the power of hosted backend services. 💼 SPONSORS [{"name": "Rollbar", "url": "rollbar.com/fullstackradio"}, {"name": "Cloudinary", "url": "cloudinary.com"}] 🏷️ Client-Side Architecture, JSON API, Ember.js, Rails API Development

Read Full Summary Listen

133: Sam Selikoff - Building Production-Ready SPAs Fast with Mirage.js

Full Stack Radio

Jan 29, 202063 minDeveloper/Creator of Mirage.js

AI Summary

→ WHAT IT COVERS Sam Selikoff explains Mirage.js, an API mocking tool that intercepts HTTP requests in JavaScript applications, enabling front-end developers to build production-ready features without waiting for back-end APIs by creating an in-memory database alongside their development workflow. → KEY INSIGHTS - **Development workflow integration:** Mirage runs in the same process as your front-end application without requiring separate terminal tabs or port configurations. Import the library into your bootstrap file, instantiate the server in development mode, and define endpoints that intercept fetch requests while maintaining identical application code for production. - **In-memory database layer:** Mirage maintains referential integrity across route handlers through a shared JavaScript object database. Create data using factory patterns inspired by Rails' factory_bot, define relationships like director-has-many-movies, and mutations persist across navigation without managing foreign keys manually, enabling realistic multi-page workflows during development. - **Testing and development code reuse:** The same route handler definitions work in both development and testing environments. Tests start with an empty database and use server.create to set up specific scenarios, while development uses seed hooks. This eliminates duplicate mocking code and keeps tests focused on assertions rather than API implementation details. - **Serializer layer flexibility:** Mirage separates database conventions from API response formats through a serializer layer. Store data using camelCase JavaScript conventions internally, then configure serializers for JSON API, Active Model Serializer, or custom formats. Built-in serializers handle root keys, meta information, and relationship linking without changing database structure. - **State management advantages:** Front-end developers can define multiple data scenarios locally without coordinating shared staging environments or running complex back-end infrastructure. Switch between states like anonymous user, subscriber, or admin by changing variables in seed files. Hot module reloading applies data changes instantly without restarting servers or running database migrations. → NOTABLE MOMENT Selikoff reveals that some development teams have successfully deployed Mirage-powered prototypes to production using local storage for persistence, creating fully functional demos for sales teams. Future plans include generating real Node.js back-end servers directly from Mirage definitions, potentially eliminating the need to manually build APIs for data-driven applications. 💼 SPONSORS None detected 🏷️ API Mocking, Front-End Development, JavaScript Testing, SPA Development, Developer Tools

Read Full Summary Listen

Never miss Sam Selikoff's insights

Subscribe to get AI-powered summaries of Sam Selikoff's podcast appearances delivered to your inbox weekly.

Start Free Today

No credit card required • Free tier available