DEV Community: Aishwarya Borkar

Getting Familiar with GraphQL

Aishwarya Borkar — Mon, 04 May 2020 18:16:16 +0000

🧰 Wherever you are in your web development journey, a knowledge of GraphQL is worth stashing in your developer toolbox.

Let's begin with a visual metaphor à la Maggie Appleton.

Scenario #1:
👋🏽 Say hi to Sally. She's eating at her favorite sit-down Italian restaurant tonight. She decides on the carbonara and flags down a waiter to take her order. The waiter relays the order to the chef. When the food is ready, the waiter brings out Sally's food. Bon appétit!

But Sally is pretty restricted by the restaurant's menu. She cannot customize what ultimately ends up on her plate. She wants to order more food, but she has to flag down the waiter and the cycle begins again. On top of that, each item adds to her total bill.

Scenario #2:
💸 Imagine if Sally was at an all-you-can-eat buffet. She has more freedom to choose what she eats for a flat price and limited interaction with a waiter or cashier to order her food and pay her bill. Seems like a better experience overall!

The lifecycle of a HTTP request.

If we liken Sally's situation to the lifecycle of a HTTP request, we can see that:

Sally is the client initiating a request,

the waiter is the HTTP protocol interacting with the server, and

the chef is the server returning the data.

💡 Scenario #1 vs. Scenario #2 is how I visualize the difference between leveraging a traditional REST API for data fetching and leveraging GraphQL on top of the API layer for customizing the data fetched. Sally does not have to initiate as many requests in Scenario #2 to get more food. And it costs her less to do so!

On a very high level, GraphQL allows us to minimize the number of API requests made and accordingly, to improve performance of web applications. In the next post, we'll shift back to developer-speak, discuss a technical use case, and implement a GraphQL query on top of an API for said use case.

What are some resources you have used to better understand GraphQL? Comment below!

Women of React 2020 Recap!

Aishwarya Borkar — Mon, 27 Apr 2020 21:23:27 +0000

When I first registered for the Women of React conference, I wasn't sure what to expect. I've never been to a purely technical conference before, that too a completely virtual one. Especially since I've lost the concept of time and a healthy sleeping schedule (thanks quarantine), I figured there was no way I'd wake up in time for the conference to start.

Narrator: Little did Ash know that she was about to be glued to her screen for the new few hours, ignoring her FitBit nudges to get up and walk around.

Okay, well, can you blame me? Cassidy Williams absolutely nailed it as MC and seamlessly segued from one talk to another. Speaking of talks (there's a pun in there somewhere), it honestly felt like the organizers had read my mind and curated a list of topics tailored towards my interests. How did they know...

My reaction to all the talks.

If you weren't able to virtually attend on Saturday, worry not! I got you. Keep on reading and comment below which talk or session you found the most helpful. 🤓

🧩 TL;DR Accessible Components:tips for building out accessible components
🗣 Yuraima Estevez
👉 Timestamp
👉 Slides

Have you found yourself passionate about #a11y but not knowing where to start? Yuraima breaks it down into 3 easy steps: semantic HTML, ARIA attributes, and keyboard navigation. When it comes to semantic HTML, there are over 100 elements yet somehow divs and spans are the most commonly used. You cannot easily infer their purpose from their names. So use button instead of div!

🎨 Design Systems
🗣 Neha Sharma
👉 Timestamp
👉 Slides

Neha's talk left me buzzing with ideas. Not that I consider myself a design system expert (heck, I learned about the concept of atomic design for the first time during her talk!) but I do enjoy maintaining the design system at my workplace. Thanks to Neha, I'm going to propose that a template for a component to make it easier for other developers to contribute to the design system and that we can integrate Lighthouse analysis into the CI/CI pipeline for the components repository.

📈 Level up your Design System with styled-system
🗣 Taley'a Mirza
👉 Timestamp
👉 Slides

I silently cheered when I watched Taley'a talk about styled-system because I remembered how it initially confused the heck out of me when I was still relatively new to design systems. Talks like this always help me refocus on the why. Using styled-system makes it easy to apply styles responsively across breakpoints. I imagine this is especially important since for a lot of websites, most of the traffic is originating from mobile browsers!

🔥 Fireside Chats 🔥
🗣 Cassidy Williams, Rachel Nabors, Sara Vieira, Jenn Craighton, Pariss Athena, Shruti Kapoor
👉 Timestamp

I've always wondered if I know enough about a certain topic to give a talk on it. Hearing from these ladies was a great confidence boost. Check out the following thread for their tips 👇

const ash = require('ashc0des');

@ashc0des

I love these tips on conference talks!

😣 Admit you're nervous, it humanizes you and people can relate to you more.

🤔 Curate conference topics by picking out what you felt another talk didn't cover and want to know more about.

#womenofreact2020

19:56 PM - 25 Apr 2020

2 6

👩🏻‍🎨 Drawing the Invisible: How to Explain React through Visual Metaphors
🗣 Maggie Appleton
👉 Timestamp
👉 Slides

This talk was a breath of fresh air. Like wow. Here's a peek into one of Maggie's metaphors 👇

I appreciated the callout to focus on metaphors that are universal, and not particular to one language or culture. Using visual metaphors allows more people to understand typically abstract programming concepts. I plan to give a demo at work around Maggie's philosophy and whip up some metaphors of my own to sell my coworkers on the notion that visual metaphors will lead to improved documentation and a happier developer experience.

🛠 React DevTools
🗣 Anushree Subramani
👉 Timestamp
👉 Slides

I loved Anushree's storytelling. I wish I had a mentor like Radhika to guide me through frontend development without judgment. Seriously, where can I find myself a Radhika?! It was also a wakeup call to realize the extent to which I could be leveraging DevTools instead of console.log!

⚡️ Lightning Talks ⚡️
🏝 Self-care in tech
🗣 Carolyn Stransky
👉 Timestamp
👉 Slides

This talk was the cherry on top of a sundae (sundae = amazing conference). Adjusting to work life balance during quarantine has been tough, and compounded with my imposter syndrome, I've been feeling quite down on myself lately. I needed this reminder to take a step back and to nourish my mental health.

🧪 Testing, tEstIng, TeStInG or how to test React apps with generated input data
🗣 Olena Sovyn
👉 Timestamp
👉 Slides

A common painpoint for testing is manually generating input data for all the various combinations of use cases. Sure, you can copy paste, but Olena provides you an alternative with unit test templates and property based testing. I'm definitely going to refer to her slide on Cartesian product for how to calculate the amount of input data needed.

⚖️ Button vs. Div
🗣 Jen Luker
👉 Timestamp
👉 Slides

Jen expands on the example that Yuraima had referred to in her talk and demonstrates (live!) what goes into making a div accessible. Folks, I am completely sold on semantic HTML at this point.

🔍 React Finding the Fun: Using TDD with React
🗣 Eve Porcello
👉 Timestamp
👉 Slides

All right, who agrees that Eve deserves an Oscar for her accurate portrayal of a developer writing tests? Major props for sneaking in a costume change AND coding live. TDD is a strategy I'm going to implement to unblock myself when I'm coding in a new language. Confession: I always get hung up on syntax and forget to focus on universal concepts. Reading tests and running tests is a great way to get up and running in a new language because you don't have to worry about the nuances of the language and you learn what to expect with regards to how the code should behave.

💼 Preparing for React tech interviews
🗣 Adrianne Valdivi
👉 Timestamp
👉 Slides

Fun fact: I actually had Adrianne's slides bookmarked from when I needed to brush up on my React knowledge for job interviews. You should too. She does a great job of focusing on what companies are most interested in when interviewing frontend candidates.

Unfortunately, I had to log off early and miss the Q&A with the React core team, but I plan on updating this article when I go back and watch the livestream. :)

Lessons Learned from a Rotational Software Engineer - Part 1

Aishwarya Borkar — Wed, 28 Aug 2019 04:57:15 +0000

Hi! I'm back with another post as I recently graduated from my two year rotational program. It was my first job post-college so it's very surreal how fast time flew. 🥳

Now is the perfect time to reflect on what I've learned in the past two years. I did 4 rotations, 2 as a software engineer, 1 as a site reliability engineer, and 1 as a platform product manager. In Part 1, I'll talk about my first two rotations, and save the other two rotations for Part 2 since they aren't strictly dev roles.

As a software engineer with 6 months per rotation, I generally
🕸Coded in React & Polymer
📝Wrote unit tests using Mocha, Chai, Cucumber, & Selenium
🧠Received technical & business trainings both domestically & internationally
🤝Collaborated with UX designers, UI developers, QA testers, tech leads, PMs
🎓Volunteered for buildOn as a mentor through their Career Readiness program for high school students

Overall, it was a fantastic experience. The nature of the rotational program has enabled me to adapt quickly to changing priorities and to overcome any learning curve set in front of me. If you think about it, it's like a six month audition per team in which you have realistically about 3 weeks to onboard and to become a contributing member.

What Did I Learn?

The most important lesson I want to share with all of you is the importance of understanding the bigger picture and of understanding how the application on which I'm working is architected and the design decisions factored into it, whether I have 6 months, 1 year, or more on the team. If I don’t put in the additional effort to understand the bigger picture, my contributions or how I communicate them to my friends, my peers, and my managers will be isolated to the part of the overall application on which I worked.

Think of it this way. Imagine if puzzle pieces didn’t come with a picture of the solved puzzle on the box. How would you assemble the pieces together without knowing what the final result looked like? 🤔 Relating this back to engineering, I'll have only understood a fraction of the application's complexity based on my pull requests.

I translated this lesson into three key points, summarized below:

✅ Top-down vs bottom-up thinking
✅ Identifying technical tradeoffs & communicating them
✅ Understanding my individual impact on the entire system

Top ⬇️ or Bottom ⬆️?

Yes, I borrowed this concept from recursion and dynamic programming.

Term	Definition	Example
Bottom Up	You start with a small step, and each step builds upon the previous step until you reach your goal.	I'm going to learn how to program in Java, then practice, then take part in coding contests, and eventually, be an amazing software engineer.
Top Down	You define the goal first, then further refine it into smaller goals.	I'm going to be an amazing software engineer. How? I will study really hard. How? I will take notes and write sample programs. On what? I will take a course on Java and use an IDE.

I prefer top-down thinking because, well, I am a top-down thinker. It’s difficult for me to move forward with a concept until I’ve understood its importance with regards to how it fits in with the bigger picture. When I was first introduced to programming, it was through Java. By making a robot named Karel move. This way of learning didn’t click, primarily because I was unmotivated by the goal of programmatically maneuvering Karel through a maze.

So what changed?

💡 Reading Web Architecture 101 by Jonathan Fulton. The subtitle itself "The basic architecture concepts I wish I knew when I was getting started as a web developer" resonated with me SO much.

"So THAT's what a load balancer is! THAT's why API design is important and so hotly debated! Caching, CDNs, all these ways to improve performance and availability - wow!" - Me, circa May 2019

In short, I used the web architecture in the article above as a blueprint and delved into its specific components to further my understanding. Hence top-down thinking.

It's All About Tradeoffs ⚖️

But knowing these terms isn't enough. Arguably, as you level up in seniority as a developer, you take on more responsibilities in scoping out projects, proposing designs, and justifying said designs to your colleagues.

I know nothing can really replace practical experience in this area and I'm not suggesting anything can. What I am saying is by understanding the types of decisions developers have to make and the types of questions they have to ask, I can feel more empowered to take part in design meetings despite being junior and to apply this understanding to the work assigned to me and to the existing application architecture.

Might I suggest a hack?

💡 Studying systems design. Even if you aren't actively interviewing.

Systems design is a multi-headed beast on its own. Many different potential approaches but it's an exercise in technical communication and technical depth. Watching YouTube videos on frequently asked systems design questions such as designing Google Maps or TinyURL were extremely informative.

It helped me formulate a framework to approach these types of problems:
💭 How to refine the scope of the problem - alignment on the # of Monthly Active Users (MAUs), on the features to be discussed, on special considerations
💭 How to structure the discussion - begin with data modeling, API design, interaction between components of the system, discussion on how to improve performance & ensure scalability
💭 Databases - why NoSQL vs SQL? What are advantages/disadvantages of either? What techniques exist to ensure availability of databases as the amount of data scales?
💭 Database replication vs. partitioning - What are advantages/disadvantages of either?
💭 Microservices vs. monolith - What are advantages/disadvantages of either?
💭 Load balancing & API gateways - can API gateways in microservice architecture be considered a type of load balancing technique?

I could go on forever. You start to see that the questions often segue into the next and are focused on advantages/disadvantages of one approach over the other. This knowledge acquisition helped me introspect on the first two teams I worked on as a rotational software engineer and will help me in the future as well.

Be Empowered 💪🏼

Any contribution is significant, no matter how big or small, front-end or back-end, QA, etc. Think about it - no matter what your role on a dev team, understanding the system will help you perform better. At the very least, it will help you confidently talk about your past work experiences or avoid downplaying by hastily summing up your contribution as "Oh, I was a front-end engineer on that team" or "I worked on the back-end mostly". Take pride in your work! Elaborate!

In short, figure out what type of learner/thinker you are, understand architecture at a high-level and design decisions associated with said architecture, and then apply it to your own work for that application. This really worked for me, and I hope it works for you, too.

🌎 4 Ways To Make Impact Everyday 🌎

Aishwarya Borkar — Fri, 02 Aug 2019 21:55:01 +0000

I am super inspired by Mindy Kaling and I want to pay it forward the way she did. I may not be a celebrity or rich but I think it's awesome that there are ways us ordinary human beings are empowered to give back.

Mindy Kaling

@mindykaling

I’m so grateful to have my wonderful, peaceful life w/ my daughter Katherine. How lucky am I to turn 40? I would love to express my gratitude by donating $1000 to 40 different charitable orgs that help others. Pls suggest some! I will kick it off by giving $1000 to @RAICESTEXAS!

18:10 PM - 24 Jun 2019

6546 99482

That being said, these are a few of the ways I like to contribute positively to the world simply by using apps or the Internet the way I normally do! Additionally, being involved in the nonprofit sector - through the Society of Women Engineers and now PERIOD.org - definitely forced me to be creative when it came to fundraising.

Forest 🌳

I actually mentioned this in the most recent #DevDiscuss re. productivity, but Forest incentivizes less time spent on your phone by translating that to more points towards planting a tree in real life. If you use your phone before the timer is up, your virtual tree dies and you don't get any points. Better luck next time!

Try not to use your phone before the timer is up.

Lyft 🚕

If you swipe to the left in the Lyft app and select 'Donate', you will be taken to the following page where you can opt-in to this feature, in which your fares will be rounded up to the next dollar and the difference will be donated to a charity of your choice.

Choose 'Donate' and your preferred charity.

Amazon Smile 😊

I know Amazon has come under fire for its treatment of warehouse workers, and I do not condone that. The fact remains that millions of people use Amazon Prime and its free two-day shipping. So why not donate along the way? You must remember to go to smile.amazon.com instead of amazon.com and select your preferred charity. It's recommended to bookmark Amazon Smile so you don't forget.

Bookmark Amazon Smile in your browser.

Tab for a Cause 💻

A browser extension that donates money to charity every time you open a new tab.

Tab for a Cause.

What are some ways you all like to give back? Are there are any apps or websites that I missed?

Shifting to a Web Dev Perspective: Two Concepts I Wish I'd Mastered

Aishwarya Borkar — Wed, 31 Jul 2019 00:04:20 +0000

In my last blog post, I talked about why I’m taking a deep dive into web fundamentals. Through both academic and professional experience, I found it very easy to succumb to the pitfalls of following tutorials and relying on StackOverflow to get things working. You can check it out here.

My ultimate goal is to be a more empowered developer who codes with #a11y and purposeful design in mind. I’ll discuss the misconceptions I had going in at the beginning of this journey (back in March), and what I now understand.

Misconception: Relationships between components in React are the same as the hierarchical relationships between classes in Java.

Not at all. In fact, there are few instances in which classical inheritance is the solution. I mistakenly equated the terms parent and child components with parent and child classes. The downside to classical inheritance is the tight coupling formed between classes in the name of code reusability. What helped me realize the downside was the gorilla banana problem.

“What you wanted was a banana, what you got was a gorilla holding the banana, and the entire jungle.”

So that roughly translates to children inheriting behavior from the parents that they might not necessarily need. Refactoring code into small units of functionality or object composition makes WAY more sense than inheritance. A component should theoretically only be responsible for one thing. If the responsibilities grow, it might be time to refactor into subcomponents. Components are nested within each other, hence the “composition”. That’s how props in React are passed from component to component.

Aishwarya Borkar 🎧👩🏻‍💻

@ashc0des

Follow up: classical inheritance doesn't exist in #JavaScript. Instead, you have the prototypal pattern & the constructor pattern.

Now, the constructor pattern DOES resemble inheritance in Java & that's bc the creator of JavaScript wanted to make JavaScript more marketable. 🙃

04:10 AM - 22 Mar 2019

0 0

As you can tell, I’ve been wrapping my brain around inheritance, how it pertains to JavaScript, and how it differs from Java for a while now. But it’s extremely fascinating and helping me formulate opinions on web fundamentals, which in my opinion, is a sign of advancing as a dev.

Recommended reading:
📖 Composition vs Inheritance

Misconception: CSS doesn’t require mastery, just working knowledge.

CSS is NOT as easy as it seems. I remember now the amount of times I would try to get a side project going and think I would achieve the most beautiful UIs by thoughtlessly copy pasting CSS snippets from StackOverflow or by relying on CSS selectors. Strangely enough, those code snippets only worked about 3 out of 10 times. I would get ragequit the other 7 out of 10 times, orphaning another side project in the process. This time around, I used the handy-dandy Dev Tools to debug CSS, and I noticed my CSS styles were being overridden by something called User-Agent Stylesheet. My first impression was who is User-Agent and is this proof that the FBI is really monitoring our every move? Kidding, of course. For the first time, I understood the CSS Cascade algorithm, and how the 3 potential origins of CSS rules (User-Agent, User, and Author) are pitted against each other and the victor determines the style of the web page. Well, not quite. The origin is the most weighted factor into the outcome of which styles are eventually rendered.

Recommended reading:
📖 How CSS works: Understanding the cascade

Bear in mind, I identified these two concepts that I should've focused on prior to starting my job as a front-end developer on enterprise IoT applications. On a story by story basis, I contributed to the codebase with relative ease but when tasked with a feature that touched many views in an application, I struggled with putting the pieces together and why our code was structured the way it was. Mentally, I was projecting Java concepts onto a React application, and underestimating CSS.

Moving forward, I want to tackle the following:
⚛️ Props vs. state
⚛️ Redux for state management
⚛️ CSS specificity
⚛️ DOM concepts
⚛️ Pure functions
⚛️ React hooks

Thanks for tuning in! Please let me know if there's anything I should add to my list of what to focus on :)

When you say you know a particular front-end language, library, or framework, what does that mean?

Aishwarya Borkar — Thu, 21 Mar 2019 01:55:06 +0000

For clarification, I'm wondering how accountable you are held when you list HTML, CSS, React, JavaScript, Angular, Node, or anything of that nature on your resume. In the past, I've said to an interviewer that I know HTML which I thought I did... and of course, he asked me a HTML question which I didn't know the answer to.

I've generally defaulted to Java as my interviewing language of choice so front-end interviews are a whole new ballpark for me. Around August, I will be rolling off my rotational program into a dedicated role in my company and I know that I would love a front-end developer role. So what are the types of concepts I should know for the aforementioned languages? Data structures & algorithms? Best practices?

git cherry-pick webdev

Aishwarya Borkar — Tue, 19 Mar 2019 00:57:14 +0000

It’s easy enough to be tasked with a small bug, run the app locally, put breakpoints, and debug the code using Chrome Developer Tools. It’s easy enough to be assigned a small user story that adds a dropdown to a form and requires modification to the form payload, and to follow the practices set forth by the senior UI developers on the team when submitting a pull request against master for the user story. That’s what got me hooked in the first place. I love the instant gratification aspect of front-end development, and I love creating reusable components.

Guilty as charged.

I started with Java, an object-oriented language, unlike JavaScript, a dynamic language. Most of my college courses and projects were extensively in Java. The programming mindset I had obtained from learning Java helped tremendously at hackathons and at internships, even though they were web dev. I experimented with Telerik, a platform for hybrid app development, at my first hackathon, and to the astonishment of my team, we won first place. I worked with Angular 1.0 at my first internship, ventured into the realm of Node.js at the next one, then Polymer in my first rotation of the career accelerator program for which I work full-time, and finally, React/Redux in my second rotation.

Notice a common theme?

A lot of tinkering, a lot of JavaScript frameworks, a lot of that scrappy perseverance to ship code, and a whole lot of Googling and StackOverflow. And yet, the focus on fundamentals is mysteriously absent.

In other words... does anyone remember learning how to manually find the derivative of a polynomial using the definition of a derivative and what a pain it was? Then finding sweet salvation in the power rule?

Having to do all this work.

Versus this easy quickhand way of differentiating.

What does that have to do with anything? Well, when you think about it, you fully understand and appreciate what you’re doing when using the power rule because the previous way was more tedious. If you had started out differentiating with the power rule, you were essentially taking a shortcut. In a similar way, I’ve consistently skipped to using the JavaScript equivalent of the power rule and hacking together solutions and as a result, I’m rusty on JavaScript fundamentals and understanding both the power and limitations of vanilla JavaScript. Why React? Why Node? Why Vue? Why Backbone? Why Ember? The answer to the why can only be found in the basics.

And back to the basics I go. 🚀

Hello World! (TheSQL)

Aishwarya Borkar — Sun, 10 Mar 2019 03:18:09 +0000

Hi.

This is my first foray into joining a developer community! I’m excited to be here.

As every programmer’s typical first successful program is printing out Hello World! to the system console, I thought it would be a fitting description for my first post as an experienced programmer wanting to start over. Also, I can never pass up the opportunity for a good pun (sequel, SQL).

So what brings me here?

Judge me if you must...but I was watching Set It Up on Netflix, and the scene where the main character’s best friend lovingly berates her for being so afraid of to fail that she hasn’t even tried hit close to home. Of course, her first draft for the article she’s working on is going to be terrible, but she’ll go back and improve it. But she has to actually write it first.

In a similar way, I’ve been holding myself back. Perhaps a classic case of imposter syndrome. I’ve always chosen what’s safe. I dabble in things, I start online tutorials for a new framework, I bookmark helpful articles and categorize them, I sign myself up for info sessions on a certain buzzword technology or a conference, but I lose sight of the takeaway and the why. I overcommit myself and it looks something like this:

The end result is that I’ve learned about what distinguishes Angular from React, I’ve read one off articles about how to tinker with CSS, and I’ve made sure to apply to a PR at work as well as document my learnings for the future. I’ve gotten a Product Owner certification, and I’ve considered getting a Splunk Power User certification. Yet, I feel light years away from becoming a subject matter expert on any of the languages and frameworks I’ve utilized, and this is what leads to the fear of failure and of falling behind where an engineer two years post-grad should be.

However, I think it’s natural for a young professional in the tech industry to see the accomplishments of her/his peers, be it on Twitter, LinkedIn, or even Facebook and become discouraged when she/he realizes there’s more she/he could be doing. It’s hard not to compare. I abandon the tutorials I’ve started when I start to feel overwhelmed, and once bookmarked, the articles I read once collect figurative dust.

As the two years in the career accelerator program I’m in wind down, there’s no time for that. I’m here in this community now to hold myself accountable to my goals. The why I seek isn’t because it will help me network or because everyone is doing it, but because it’s what truly matters to me. In true Silicon Valley fashion, I will start by productizing my goals, refining them into features, prioritizing the features based on timeframe and the value added to my career, and further refining them into action items that I can deliver over the course of 2 week sprints. Okay, mostly joking, but here’s to a focused, Marie Kondo-esque plan!