DEV Community: Santhanam Elumalai

Building a Robust API Layer - `api-def` Package Integration with React (NextJs) app

Santhanam Elumalai — Sat, 28 Sep 2024 23:26:21 +0000

Welcome back! In this part, we'll demonstrate how to integrate the api-def package with a Next.js application for client-side and server-side API fetching using Tanstack Query.

Recap:

We explored the concept and implementation of the api-def package.

Integration with Tanstack Query:

Configure Tanstack Client:
- Create a Providers component to manage the QueryClient instance.
- Use isServer from @tanstack/react-query to create separate clients for server and client.

  import { QueryClient, QueryClientProvider, isServer } from "@tanstack/react-query";

  function makeQueryClient() {
      return new QueryClient({
          defaultOptions: {
              queries: {
                  staleTime: 60 * 1000, // Cache timeout in milliseconds
              },
          },
      });
  }

  let browserQueryClient: QueryClient | undefined = undefined;

  function getQueryClient() {
      if (isServer) {
          return makeQueryClient();
      } else {
          if (!browserQueryClient) {
              browserQueryClient = makeQueryClient();
          }
          return browserQueryClient;
      }
  }

  export function Providers({ children }: { children: React.Node }) {
      const queryClient = getQueryClient();
      return <QueryClientProvider client={queryClient}>{children}</QueryClientProvider>;
  }

Provider Placement:
- Wrap your application with the Providers component at the root level (e.g., in layout.tsx) to make the QueryClient context globally accessible.

  import { Providers } from "./providers";

  export default function RootLayout({ children }: { children: React.Node }) {
      return (
          <html lang="en">
              <body>
                  <Providers>{children}</Providers>
              </body>
          </html>
      );
  }

Client-Side Fetching:
- Create a component (e.g., Users component) that utilizes the useQuery hook from Tanstack Query.
- Use the GetUserKeys function from api-def to define the query key for caching and invalidation.
- Use the ApiClient from api-def within the queryFn to fetch data from the API.

  import { GetUserKeys, ApiClient } from "@repo/api-definitions";
  import { useQuery } from "@tanstack/react-query";

  export function Users() {
      const { data } = useQuery({
          queryKey: GetUserKeys.getUsers({}),
          queryFn: async ({ queryKey }) => {
              const queries = queryKey[0]?.requestBody;
              return ApiClient.getUsers(queries || {});
          },
      });

      return <>{JSON.stringify(data)}</>;
  }

Server-Side Prefetching:
- Within a server component (e.g., in page.tsx), prefetch the data using queryClient.prefetchQuery before rendering the component.
- Use the same GetUserKeys and ApiClient from api-def within the queryFn for consistency.
- Wrap the component with a HydrationBoundary from Tanstack Query to hydrate the prefetched data on the client.

  import { dehydrate, HydrationBoundary, QueryClient } from "@tanstack/react-query";
  import { GetUserKeys, ApiClient } from "@repo/api-definitions";
  import { Users } from "@app/user/users";

  export default async function PostsPage() {
      const queryClient = new QueryClient();
      await queryClient.prefetchQuery({
          queryKey: GetUserKeys.getUsers({}),
          queryFn: ({ queryKey: [requestBody] }) => {
              return ApiClient.getUsers(requestBody?.requestBody || {});
          },
      });
      return (
          <HydrationBoundary state={dehydrate(queryClient)}>
              <Users />
          </HydrationBoundary>
      );
  }

Benefits:

Type safety: Zod ensures type safety throughout the API interactions.
Centralized definitions: api-def offers a single source for API definitions and endpoints.
Efficient caching: Tanstack Query manages caching and invalidation for optimized performance.

Next Steps:

In the upcoming post, we'll delve into the integration of another powerful tool: React Hook Form. This library will help us streamline form handling, validation, and submission processes within our React applications.

Stay tuned!

Github PR Location

Footnote: This implementation is inspired by the Tanstack Query documentation on Advanced Server-Side Rendering: Advanced Server Rendering

Building a Robust API Layer - Implementation with `api-def` Package

Santhanam Elumalai — Thu, 26 Sep 2024 01:38:37 +0000

Continuing our series, let's delve into the practical implementation using the api-def package.

Recap:

We explored the concept of the api-def package in the previous post.
It centralizes API definitions and provides a consistent interface for making API requests.

Implementation Breakdown (Part 1: api-def-package Setup)

Project Setup:

Existing Project: Assuming you've bootstrapped your application based on the previous post Bootstrapping With Turbo Repo.
Dependencies: Install the required packages using npm or yarn:
```
 npm install @zodios/core zod typescript axios eslint
```

API Definition:

Create a folder named user under src to store API definitions specific to user data.

Define the API schema using Zod:

 import { z } from "zod";

 export const UserProfileSchema = z.object({
   firstName: z.string(),
   lastName: z.string(),
   email: z.string().email(),
 });

 export const Users = z.array(UserProfileSchema);

 export const UserSchema = {
   UserProfileSchema,
   Users,
 };

Create separate files for types and query keys for better organization.

API Endpoint:

Use Zodios to create the API endpoint for fetching users:

 import { makeEndpoint } from "@zodios/core";
 import { UserSchema } from "./user-schema";

 export const getUsers = makeEndpoint({
   method: "post",
   path: "user/search",
   alias: "getUsers",
   parameters: [
     {
       type: "Body",
       name: "getUsersPayload",
       schema: UserSchema.UserProfileSchema.partial(),
     },
   ],
   response: UserSchema.Users,
 });

Query Key:

Define a method to generate query keys for caching and invalidation:

 import { User } from "./user-type";

 export const GetUserKeys = {
   getUsers: (requestBody: Partial<User.UserProfile>) => {
     return [
       {
         requestBody,
       },
     ];
   },
 };

API Client:

Create an API client using Zodios to make API calls based on the defined endpoint:

 import { Zodios, makeApi } from "@zodios/core";
 import { getUsers } from "./user/user-endpoint";

 const api = makeApi([getUsers]);
 export const ApiClient = new Zodios("http://localhost:3000/api/", api);

Export:

Export all the components (schemas, types, query keys, API client) from a central index file:

 export * from "./queryKey";
 export * from "./schemas";
 export * from "./types";
 export * from "./apiclient";

This completes the implementation of the api-def package. In the next part, we'll demonstrate how to integrate this package with a Next.js application for client-side and server-side API fetching.

Github PR Location

Stay tuned for the next post!

Building a Robust API Layer with TypeScript, Tanstack Query, Zod, and Zodios

Santhanam Elumalai — Tue, 17 Sep 2024 00:57:21 +0000

Introduction

Welcome back! In this part of our series, we'll dive deeper into the api-def package and its benefits.

In today's data-intensive applications, ensuring seamless communication between the frontend and backend is paramount. This blog post will delve into how we can establish a robust API layer using TypeScript, Tanstack Query, Zod, and Zodios. By leveraging these powerful tools, we can achieve type safety, efficient data management, and a centralized approach to API interactions.

The Problem: Inconsistency and Errors

Traditional JavaScript-based applications often suffer from inconsistencies between frontend and backend data structures. This can lead to unexpected errors and difficulties in maintaining code quality. To address these challenges, we need a more structured and type-safe approach.

Solution: TypeScript and Zod

TypeScript: By adopting TypeScript, we can introduce strong typing to our codebase. This ensures that data structures are defined precisely, reducing the likelihood of runtime errors.

Zod: Zod is a powerful schema validation library for TypeScript. It allows us to define the structure and validation rules for our data. This ensures that data entering our application adheres to the expected format, preventing invalid input from reaching the backend.

API Requests with Tanstack Query

Tanstack Query is a popular library for managing asynchronous data fetching in React applications. It provides features like caching, invalidation, and query management, making it ideal for handling API requests.

Centralized API Management with Zodios

To maintain a consistent approach to API interactions, we can use Zodios. It acts as a factory for creating API query functions based on specified parameters. This allows us to centralize common logic, such as middleware, interceptors, and error handling, in one place.

Asynchronous Events and State Management in React

In React, asynchronous operations are typically handled using state management mechanisms. Instead of using traditional event-based callbacks, we watch for changes in the state to trigger updates in the UI. This approach ensures a more declarative and predictable way of handling asynchronous data.

Query Key Invalidation and Caching

Tanstack Query introduces the concept of query keys. These keys are used to identify cached responses. By invalidating query keys, we can trigger refetches of data when necessary, ensuring that our application always displays the most up-to-date information.

The `api-def` Package

To encapsulate the API-related logic and definitions, we can create a separate package named api-def. This package will contain:

API keys: Unique identifiers for different API endpoints.
API methods: Functions that define how to interact with the corresponding API endpoints, including request parameters, response handling, and error management.

Thanks to Tim Hazlett who proposed and bootstrapped the api-def layer.

Conclusion

By adopting TypeScript, Zod, Tanstack Query, and Zodios, we can create a robust and maintainable API layer for our React applications. This approach ensures type safety, efficient data management, and a centralized approach to API interactions, leading to improved code quality and reduced errors.

Building a Solid Foundation: Bootstrapping with Turbo Repo

Santhanam Elumalai — Mon, 02 Sep 2024 20:01:14 +0000

Introduction

In today's complex web applications, creating a well-organized and maintainable codebase is crucial. Enter Turbo Repo, a powerful tool that streamlines project management and accelerates build times for JavaScript and TypeScript projects. This post will guide you through bootstrapping a robust front-end ecosystem using Turbo Repo. We'll establish the foundation for your application by setting up the folder structure, enabling inter-package connectivity, and ensuring a clean environment.

Setting Up a Solid Structure

Turbo Repo Initialization: We'll follow the official Turbo Repo getting started guide for a smooth setup: Link to Turbo Repo getting started documentation.
Web App Refactoring and Cleanup: The default Turbo Repo setup includes a landing page and associated assets. Since these are unnecessary for our project, we'll remove them, leaving a clean src folder. To establish a consistent styling foundation, we'll incorporate a global CSS reset using Meyerweb's handy reset tool: Link to Meyerweb CSS reset.
Introducing the api-definition Package: Next, we'll introduce a new package named api-definition within package.json. This package will act as the central hub for defining all our API request structures, ensuring consistency and maintainability. We'll delve deeper into its functionalities in the next post.
UI Package Setup: The default setup includes a UI library package named UI. We'll rename it to ui-components and remove any unnecessary sample components. An index file will be added to the src folder to export all essential UI components. Furthermore, we'll include the api-def package as a dependency for ui-components, given its extensive usage within the UI components themselves. Finally, to streamline import paths within the package, we'll create a global alias name.

Conclusion

This post has established a solid foundation for your Turbo Repo project. We've set up the essential folder structure, configured inter-package connectivity, ensured a clean environment, and introduced the api-definition package. In the next post, we'll delve deeper into setting up and utilizing this crucial package – the backbone of well-defined API interactions within your application.

Note: Throughout this process, we've referred to existing configuration files like tsconfig.json and .eslintrc.js for clarity. The code snippets for these files are intentionally omitted to avoid overloading this post. However, future posts may provide detailed explanations of these configurations for a comprehensive understanding.

By following these steps and exploring the functionalities of Turbo Repo, you'll be well on your way to developing a robust and well-structured front-end ecosystem. Stay tuned for the next post where we'll dive into the api-definition package!

Below is the implementation Pull Request:
https://github.com/santhanam87/react-jam-stack/pull/1

Introducing: A Frontend Architect's Journey

Santhanam Elumalai — Sun, 01 Sep 2024 01:19:07 +0000

Welcome to my blog!

I'm excited to share my experiences and insights as a Frontend Architect at my current company. In this series, I'll delve into the challenges, triumphs, and lessons learned while building a robust frontend ecosystem for our flagship product.

One of the most significant challenges I've faced in this role has been balancing the need for innovation with the constraints of an established enterprise application. As a frontend architect, I'm tasked with modernizing our technology stack and improving developer productivity, while also ensuring that our application meets the stringent requirements of our business.

This has often meant striking a delicate balance between adopting cutting-edge technologies and maintaining compatibility with existing systems. Additionally, I've had to navigate the complexities of working with large, distributed teams and coordinating efforts across multiple geographical locations.

Despite these challenges, I've found this role incredibly rewarding. I've had the opportunity to work with talented developers, solve complex technical problems, and contribute to the success of our organization.

In the coming weeks and months, I'll be sharing more details about the specific challenges I've encountered, as well as the strategies I've used to overcome them.

Technology Stack Selection: A Balancing Act

Santhanam Elumalai — Sun, 01 Sep 2024 01:17:27 +0000

Introduction

In this post, I'll discuss the factors that influenced our decision to choose Next.js as the primary framework for our frontend ecosystem. Given the limitations of the legacy system, it was essential to select a framework that could address our specific needs and challenges.

Key Considerations

Before making a decision, we carefully considered the following factors:

Performance: We needed a framework that could handle large-scale applications without sacrificing performance.
Community support: A strong community ensures access to resources, libraries, and solutions.
Modularity: We wanted a framework that allowed us to include necessary libraries on-demand.
Hybrid approach: We sought a framework that supported both server-side rendering (SSR) and client-side rendering (CSR).
Typesafety: We prioritized a framework that enforced strong typing to prevent errors and improve maintainability.
API contracts: We needed a way to define clear API contracts between the frontend and backend.
Testing: We wanted a framework that supported unit testing and other testing methodologies.
Documentation: Comprehensive documentation is essential for knowledge sharing and onboarding new team members.

Why Next.js?

After careful evaluation, we decided to go with Next.js for the following reasons:

SSR and CSR: Next.js provides a flexible environment for combining SSR and CSR, allowing us to optimize performance based on specific use cases.
Built-in API server: The built-in API server simplifies the development process and provides a convenient way to mock data.
Static site generation: Next.js generates pre-rendered static pages, improving initial load times and SEO.
Scalability: The framework's modular architecture makes it easier to scale the application as needed.

TypeScript and Typesafety

To ensure strong typing and prevent errors, we enforced the use of TypeScript as our primary coding language. TypeScript provides static type checking during the build process, helping to identify potential issues early on.

API Management

We used Tanstack Query, Zod, and Zodios to manage API requests, responses, and validation. Additionally, we leveraged OpenAPI specifications to generate types for our APIs, ensuring consistency between the frontend and backend.

Unit Testing

While we initially considered Vitest, we ultimately chose Jest with React Testing Library (RTL) for unit testing. Although we didn't achieve 100% code coverage, we aimed for at least 80% to ensure adequate test coverage.

Documentation

To avoid the documentation challenges of the legacy system, we planned to create extensive documentation covering key implementations and processes.

Conclusion

By carefully considering our requirements and evaluating available options, we selected Next.js as the ideal framework for our frontend ecosystem. In the next post, I'll discuss the process of bootstrapping the application with a GitHub repository.

Laying the Foundation: Bootstrapping a New Frontend Ecosystem

Santhanam Elumalai — Sun, 01 Sep 2024 01:15:37 +0000

Introduction

In this post, I'll delve into my initial task: bootstrapping the application with a robust frontend ecosystem. Given the challenges of the legacy system, my goal was to establish a more efficient and maintainable development environment.

The Legacy Landscape

The legacy system, built on Angular 1.x, suffered from several critical issues:

Inflexible component library: The existing component library, xLib, was difficult to modify or extend.
Lack of API contracts: Frontend and backend communication was inconsistent and error-prone.
Inconsistent design: The absence of design standards led to a fragmented and visually unappealing interface.
Lack of typesafety: Untyped data access made it difficult to prevent errors and ensure data integrity.
Limited design patterns: The development team was constrained by legacy design decisions.
Absence of testing: No unit or end-to-end tests were in place.

A Process-Oriented Approach

To address these challenges, we adopted a process-oriented approach:

Standardized design: We implemented a design system with predefined templates to ensure consistency.
Component-based development: We created a reusable component library to streamline development.
Turbo monorepo: We used a monorepo structure to manage our project and its dependencies.
Next.js and TypeScript: We chose Next.js for its server-side rendering capabilities and TypeScript for strong typing.
Additional libraries: We selected Tanstack Query for data fetching, React Hook Form for form handling, Zod for schema validation, and Voided for error handling.

Building a Reusable Component Library

Rather than building the entire component library at once, I focused on creating a complete profile screen with mock data. This approach allowed me to identify the essential components needed for the application.

Bootstrapping the Application

To provide a solid foundation for future development, I bootstrapped the application using a Turbo monorepo. This structure allowed us to organize our code into separate packages, including the component library and the main application.

Conclusion

By carefully considering the legacy system's limitations and adopting a process-oriented approach, we were able to establish a more efficient and maintainable frontend ecosystem. In the next post, I'll discuss the reasons behind our choice of Next.js and other key libraries.

Beyond the Code: A Guide to Effective Code Reviews as a Front-End Engineer

Santhanam Elumalai — Wed, 17 Apr 2024 00:02:58 +0000

Beyond the Code: A Guide to Effective Code Reviews as a Front-End Engineer

Code review is a cornerstone of software development, and as an experienced front-end engineer, you understand it's more than just checking for syntax errors. It's a collaborative effort to ensure clean, maintainable, and well-structured code. Here's a breakdown of my approach to code reviews, focusing on both general aspects and front-end specific considerations.

Setting the Stage for Success

Before hitting that "submit PR" button, I make sure my code is deployment-ready. This involves running tasks like linting, testing, and building locally. This proactive approach minimizes the chances of your PR getting rejected due to basic issues.

General Code Review Principles

Business Requirements: Every PR should demonstrably fulfill a specific business need. New features, especially, require clear alignment with core functionalities. Missing functionality triggers a change request to ensure proper coverage.
Beyond Requirements: While requirements are crucial, consider additional factors that enhance user experience. These might include internationalization, feature access controls, informative help text, progress bars, and well-crafted alert messages. These elements, while not explicitly stated, contribute to a polished user experience.
Naming Conventions: Readable code is self-explanatory. Meaningful variable names act like a mini-narrative, eliminating the need for lengthy comments. If the programmer grasps their code's purpose, the variable names should reflect that intention.
Consistency is Key: When building similar screens with minor variations, I recommend enforcing a common pattern to streamline the development flow. This promotes predictability and makes variations readily apparent during review.
Test Cases and Coverage: While achieving 100% coverage can be tempting, it's essential to consider edge cases and ensure they're adequately addressed in your tests. Aim to think critically about potential corner cases and write tests that effectively handle them.
Double-Edged Sword of Reusability: Reusability is valuable, promoting abstraction and modularity. However, over-abstraction can create complex layers that become difficult to maintain in the long run. I strive for a balance, considering both the "why not reuse" and "why reuse" arguments.
Constants in their Place: Proper placement and definition of constants are essential. This ensures consistency and maintainability throughout the codebase.

Front-End Specific Considerations

The Holy Trinity: As a front-end engineer, a well-structured PR should present the code in three distinct parts: HTML, CSS, and JavaScript (or TypeScript).
Valid HTML: While I may not be overly stringent on specific markup standards, there are certain practices to avoid. Examples include nesting divs within anchor tags or adding inline onclick events to paragraph tags.
CSS - There's No Silver Bullet: CSS offers multiple paths to achieving the same layout. However, practices like using tag selectors excessively, non-standard ID-based selectors, or overriding library CSS classes are generally discouraged.
JavaScript Efficiency: Nested loops can be performance bottlenecks. If unavoidable, ensure they are optimized and called only when necessary.
Data Transformation Magic: When dealing with large datasets for searching, filtering, or other transformations, consider creating JavaScript object mappings for future reference. This improves code readability and maintainability.
Pixel Perfection: A keen eye for layout is essential. Even minor inconsistencies can disrupt the user experience. If I notice such issues, I'll clearly communicate them to the reviewer.
Typescript Power: In today's world, TypeScript reigns supreme. I avoid using any or unknown types at all costs. Their presence often indicates hidden complexities within the code.

Providing Constructive Feedback

Focus on Functionality: If the core functionality is implemented correctly, I'll typically approve the PR with comments outlining any desired changes.
Positive Reinforcement: Harsh criticism is counterproductive. I focus on providing clear and actionable feedback that fosters a collaborative environment.
Pair Programming for the Win: For complex issues, I suggest pair programming sessions to address them efficiently in a single sitting.

By following these guidelines, you can approach code reviews not just as a task, but as an opportunity to improve code quality, maintainability, and foster a positive development culture within your team.

Beyond SPAs and SSR: Why a Hybrid Approach Might Be Your Web App's Perfect Match

Santhanam Elumalai — Tue, 16 Apr 2024 14:08:15 +0000

Not Quite SSR, Not Quite SPA: Why I Chose a Hybrid Approach

Building a web application involves trade-offs. There's the classic Single Page Application (SPA) approach, where everything runs in the browser, and then there's Server-Side Rendering (SSR), where the server generates the entire HTML page. But what if neither quite fits your needs? That's where a hybrid approach can be a game-changer.

My Requirements:

Data-Heavy Screens: Multiple dropdowns pulling data on load.
Dynamic Content: Help text and error messages that change based on user interaction.
Multilingual Support: All text needs to be available in multiple languages.
Dynamic Menus: Menu structure changes based on user roles.
Role-Based Features: Feature availability depends on user permissions.
Large Menu List: A massive menu dependent on various factors.
Many Screens: Around 200 profiles and other screens.

Why Not Pure SPA?

An SPA could handle everything, but there's a catch: the initial wait. Holding users hostage while all the services load isn't ideal. Sure, we could try Suspense components, but things like dynamic menus and help text would keep the entire app in limbo.

Why Not Pure SSR?

Lazy-loading could help with a pure SSR approach, but for an application size like mine, I wasn't sure how well it would scale.

Enter the Hybrid Approach:

I wanted a lean structure that loads essential information on the server first, with the rest loading asynchronously. This lets me prepare pages with heavy data (cached on the server) and keep the initial load light.

Diving Deeper: Benefits and Drawbacks of the Hybrid Approach

We explored the high-level advantages and disadvantages of a hybrid approach for web development. Now, let's delve deeper into each point:

Benefits:

Lean Page Size & Faster Initial Load: Hybrid apps leverage the server to pre-render pages with essential data. This means less code for the browser to download initially, resulting in a quicker first impression for your users.
Server Does the Heavy Lifting: Complex data processing and calculations can be handled on the server-side, freeing up the user's device for a smoother experience. This is especially beneficial for users with less powerful devices.
Deployment Unit Size Freedom: Unlike pure SPAs where the entire application resides in the browser, the hybrid approach separates code. This allows for larger applications without worrying about exceeding deployment unit size limitations on some platforms.

Drawbacks:

Hydration Hurdles: Hydration refers to the process of turning the initial server-rendered HTML into a fully interactive client-side application. Hybrid apps can face challenges when hydrating dynamic data like dates or user-specific information. Extra steps might be needed to ensure a seamless transition from server-rendered content to fully interactive elements.
Dev Watch Mode Delays: Development environments often use watch modes to automatically recompile code changes. In a hybrid approach, this process can be slower because it might involve communication between the server and client-side code.
Global State Management Maze: Maintaining a consistent state across the entire application, especially for complex data, can be tricky in a hybrid approach. Different solutions might be needed for server-side and client-side state management, adding complexity.
Tunneling Troubles: If your internal services (APIs) are separate from the application server, accessing them might require network tunneling during development and testing. This can introduce additional configuration steps and potential security considerations.

Remember: The hybrid approach isn't a one-size-fits-all solution. Carefully weigh the benefits and drawbacks against your specific project requirements before taking the plunge.

Recommendation:

Going hybrid is a bold move. My advice? Keep your application flexible enough to transition to a full SPA as a backup plan. With this compatibility in mind, you have the freedom to explore ways to improve your application's core functionalities within the hybrid approach.

By considering both the advantages and challenges, you can decide if a hybrid approach might be the perfect fit for your next web application project.

New Tech Job? Hit the Ground Running with These First-Week Wins

Santhanam Elumalai — Mon, 15 Apr 2024 01:28:14 +0000

Hitting the Ground Running: Your First Few Weeks at a New Tech Job

So you've landed the new gig – congratulations! But before you settle in with a cup of coffee and contemplate your desk chair feng shui, there are some key actions you can take to make a positive impact right away. Here are some tips I've learned to launch yourself into a successful career path at your new tech company:

Proactive Power Plays:

Be a Code Crusader: Dive into code reviews! Don't just identify issues; suggest improvements that enhance the codebase. This showcases your technical skills and problem-solving abilities.
Expectation Excavation: Get clear on your role expectations. Understand your responsibilities and how your work contributes to the bigger picture.
Quick Contribution Quest: Assess the codebase and see where you can jump in and contribute – even small fixes demonstrate your understanding and willingness to help.
Documentation Dynamo: Become a documentation champion! Start documenting processes, systems, and code. Clear documentation is invaluable for you and your team.
Tool Time Traveler: Get acquainted with the development tools and frameworks used by the team. Aim to reach a level where you can make your first contribution.
Project Management Master: Learn the project management tools used by the team and keep your assigned tasks updated. This demonstrates organization and accountability.

Polishing Your Pull Requests:

Code Chameleon: When making your first pull request (code change submission), ensure it adheres to the existing code style. This includes code flow, variable naming conventions, and overall formatting. Consistency is key!

Building Confidence:

Work for You, Not Them: Focus on your own development and learning. Don't get caught up in office politics or trying to please everyone.
Stand Up for Your Code (Respectfully): Be prepared to defend your code during code reviews. Explain your decisions and be open to feedback. Remember, respect goes both ways.

Staying Aware:

Keep Your Ears to the Ground: Pay attention to what's happening around you. If you feel like you're being neglected, speak up politely to understand the situation.

What Not to Do:

Forced Friendliness: Don't try to be best friends with everyone immediately. Genuine connections take time.
Trust Your Gut: While respecting others, trust your instincts about situations and colleagues.
Settling In is Settling Out: Don't waste time getting comfortable. Take initiative and start contributing from day one.
The Question Quandary: Do your research before asking questions. This shows you've put in the effort to learn independently.
Judgement Calls: Observe your colleagues, don't judge them. Focus on understanding team dynamics.
The Blame Game: If a task isn't yours, don't shy away from clarifying that. Be upfront about your responsibilities.
Bragging Rights: Avoid boasting about your skills. Let your work speak for itself. Build your momentum steadily.

The Final Word: Resilience is Key

Remember, nothing is permanent. Prepare yourself for unexpected situations. This is just one step in your career journey. There will be other opportunities, so don't give up!

By following these tips and staying focused, you can make a fantastic first impression and set yourself on the path to success in your new tech role.

New Job? Here's Your First 3-Week Action Plan

Santhanam Elumalai — Mon, 15 Apr 2024 00:13:10 +0000

The First Three Weeks: Make Your Mark or Move On

One of the toughest lessons I've learned recently? Don't waste time settling in at a new company. The first three weeks are absolutely critical. Here's why:

During this initial period, you have the opportunity to establish yourself as a superhero, an average contributor, or someone who might not be the right fit for the role.

The reality? If you can't land in the first two categories within those three weeks, it might be an uphill battle forever.

Here's the honest recommendation: Don't waste those precious first weeks! Be proactive and make yourself as visible as possible.

Here are some ways to do that:

Jump right in: Ask questions, volunteer for projects, and show your eagerness to learn.
Network internally: Meet your colleagues, understand their roles.
Don't try to impress: Don't show you are trying to impress, there is a difference between self promoting and self branding.
Deliver early wins: Look for opportunities to add immediate value, even if they seem small.
Communicate effectively: Keep your manager and team updated on your progress and ask for feedback.

But what if you put in the hard work and still feel invisible?

That's a sign you might need to consider if this is the right environment for you. Don't be afraid to have an honest conversation with your manager about your concerns.

Remember, your career path is yours to define. Don't be afraid to make the call that's best for you!

#careeradvice #newjob #firstimpressions

SSR vs SPA Showdown: Choosing the Right Rendering Approach for Your Web App

Santhanam Elumalai — Fri, 12 Apr 2024 03:15:44 +0000

When to Choose SSR vs SPA

Single Page Applications (SPAs) and Server-Side Rendering (SSR) are two titans in the web development world, each offering distinct advantages for building modern web experiences. But with great power comes a great choice: which one is right for your next project?

This blog cuts through the jargon to help you pick the perfect rendering approach based on your specific needs.

In the Corner of Content King: Enter SSR

SSR shines when content reigns supreme. Here's why:

SEO Champion: Search engines love pre-rendered HTML, and that's exactly what SSR delivers. Your content is readily available for crawlers to understand and index, boosting your SEO potential.
Speedy Initial Load: Users see content instantly, thanks to the server sending a fully-formed HTML page. This is especially crucial for users on slower connections.
Accessibility All-Star: SSR ensures your app is accessible to everyone, even those with JavaScript disabled.
Social Sharing Savior: Sharing your app on social media is a breeze with SSR. The full content is there for platforms to preview, unlike SPAs that might show a blank page initially.

Prime use cases for SSR include:

E-commerce websites
Blogs and news sites
Marketing landing pages
SEO-focused applications

The SPA: Dynamic Dance Partner

SPAs excel at creating dynamic and interactive user experiences. Here's how:

Single Page Bliss: The user sees a single page throughout their interaction, leading to a smooth and seamless feel.
Offline Functionality (maybe): With clever caching strategies, SPAs can potentially function even without an internet connection.
Real-time Magic: SPAs can provide a more dynamic and real-time user experience, perfect for applications like chat or collaborative tools.

SPAs are a great choice for:

Single-purpose web applications
Dashboards and data visualization tools
Social media platforms
Real-time chat applications

The Champion You Choose

So, which rendering approach wins? It depends! Here's a quick cheat sheet:

Need top-notch SEO and fast initial load? Go SSR.
Prioritizing a seamless, dynamic user experience? Choose SPA.

Enter the Hybrid Hero: Combining the Best of Both Worlds

The good news is, you're not limited to just one approach. Many frameworks, like Next.js and Nuxt.js, allow for a hybrid solution, where you leverage the strengths of both SSR and SPA. This can be particularly useful for content-heavy applications that also require a high degree of interactivity.

Here's how a hybrid approach works:

Strategic SSR: Use SSR for critical pages or initial content loads to ensure SEO and fast initial rendering.
SPA for Interaction: Once the initial content is loaded, switch to SPA mode for a smooth and dynamic user experience on subsequent interactions.

This approach gives you the best of both worlds:

Excellent SEO: Search engines can easily index your content.
Fast Initial Load: Users see content quickly, even on slower connections.
Seamless User Experience: The application feels smooth and responsive after the initial load.

Consider a hybrid approach if:

You have a content-heavy application with SEO requirements.
Your application needs to be highly interactive after the initial load.

By understanding the strengths and weaknesses of SSR, SPA, and the hybrid approach, you can make an informed decision about the best way to build your next web application. Remember, the ultimate goal is to create a user experience that is both functional and delightful.

DEV Community: Santhanam Elumalai

Building a Robust API Layer - `api-def` Package Integration with React (NextJs) app

Building a Robust API Layer - Implementation with `api-def` Package

Building a Robust API Layer with TypeScript, Tanstack Query, Zod, and Zodios

Introduction

The Problem: Inconsistency and Errors

Solution: TypeScript and Zod

API Requests with Tanstack Query

Centralized API Management with Zodios

Asynchronous Events and State Management in React

Query Key Invalidation and Caching

The api-def Package

Conclusion

Building a Solid Foundation: Bootstrapping with Turbo Repo

Introducing: A Frontend Architect's Journey

Technology Stack Selection: A Balancing Act

Introduction

Key Considerations

Why Next.js?

TypeScript and Typesafety

API Management

Unit Testing

Documentation

Conclusion

Laying the Foundation: Bootstrapping a New Frontend Ecosystem

Introduction

The Legacy Landscape

A Process-Oriented Approach

Building a Reusable Component Library

Bootstrapping the Application

Conclusion

Beyond the Code: A Guide to Effective Code Reviews as a Front-End Engineer

Beyond the Code: A Guide to Effective Code Reviews as a Front-End Engineer

Beyond SPAs and SSR: Why a Hybrid Approach Might Be Your Web App's Perfect Match

Not Quite SSR, Not Quite SPA: Why I Chose a Hybrid Approach

Diving Deeper: Benefits and Drawbacks of the Hybrid Approach

New Tech Job? Hit the Ground Running with These First-Week Wins

Hitting the Ground Running: Your First Few Weeks at a New Tech Job

New Job? Here's Your First 3-Week Action Plan

The First Three Weeks: Make Your Mark or Move On

SSR vs SPA Showdown: Choosing the Right Rendering Approach for Your Web App

When to Choose SSR vs SPA

In the Corner of Content King: Enter SSR

The SPA: Dynamic Dance Partner

The Champion You Choose

Enter the Hybrid Hero: Combining the Best of Both Worlds

The `api-def` Package