DEV Community: Viviane Dias

Key behaviors that got me promoted to Senior developer

Viviane Dias — Mon, 02 Dec 2024 23:25:08 +0000

Becoming a senior developer is less about reaching a milestone and more about embodying certain behaviors that demonstrate professionalism, technical expertise, and leadership. Reflecting on my journey, here are some key behaviors that helped me grow into a senior role.

1. Communicate clearly

Clear communication is a cornerstone of effective collaboration, especially in technical environments. One of the most critical aspects is setting realistic expectations with stakeholders.

For example:

If a feature is technically complex or constrained by time, it's crucial to explain why the complete solution might not be feasible within the deadline. Avoid overpromising; instead, focus on realistic outcomes.

How to succeed:

When communicating constraints, suggest alternative paths:

Explain technical challenges to non-technical stakeholders: Use metaphors or simple analogies to ensure your point is understood without sounding condescending. Treat product owners and project managers as allies, working together to find solutions.
Propose simpler alternatives: Propose a simpler version of the feature as an MVP (Minimum Viable Product) to meet immediate deadlines while planning incremental improvements later.

2. Make your work visible

Keeping your progress visible not only builds trust but also prevents micromanagement. It’s a simple habit that signals your maturity and consistency.

Track your progress:

Move your task to “In Progress” when you start.
Create a pull request (PR) early and commit regularly. Push your code to remote daily—even unfinished work has value in showing progress.
Encountered a blocker? Leave comments on the issue or task describing what happened. Transparency is better than silence.

Why it matters:

By making your work visible, you allow your manager to see how you’re progressing without requiring constant check-ins. They can easily check your task board or PRs, identify potential challenges, and provide timely support.

3. Get involved

Engagement goes beyond coding—it’s about investing in your team and its success.

Lead initiatives: If your team doesn’t already have activities like knowledge-sharing sessions or tech debt discussions, take the initiative to organize them. This shows your commitment to improving the team’s processes and culture.
Contribute to existing sessions: If such ceremonies already exist, actively participate, provide feedback, and suggest new ideas for the team to explore.

Your involvement demonstrates a proactive mindset and positions you as a leader, even before formal titles come into play.

4. Dive into Technical Analysis

Taking part in technical analysis is an excellent way to deepen your understanding of the codebase, especially when you're new to a team.

Benefits:

Broader exposure: You’ll explore a range of issues and areas in the codebase without the pressure of immediately delivering a feature or fixing a bug.
Contextual understanding: This helps you connect the dots between the product’s needs and the technical solutions, making you more effective in future tasks.

5. Start leading projects

Once you’ve established yourself with the behaviors above, take the next step by leading smaller projects.

Steps to get started:

Speak with your manager and stakeholders about your interest in leading projects.
Begin with low-stakes or smaller initiatives and gradually increase the complexity.
If possible, co-lead projects with someone experienced to gain insights and share responsibilities.

Leadership is a skill you build over time, and leading projects allows you to practice decision-making, communication, and technical ownership.

Final thoughts

Growing into a senior developer is about more than just writing excellent code—it’s about demonstrating responsibility, fostering collaboration, and driving team success. By focusing on clear communication, transparency, engagement, and leadership, you’ll not only excel individually but also elevate your team and projects.

These behaviors may seem small in isolation, but together, they paint the picture of a senior developer who is professional, reliable, and ready to tackle challenges head-on.

8 essentials for every JavaScript project

Viviane Dias — Mon, 18 Nov 2024 13:47:23 +0000

As a developer, especially if you’re new to a team, one of the fastest ways to add value is by introducing tools that improve the day-to-day workflow. These tools help maintain code quality, ensure consistency, and streamline the development process. Here’s a list of what I consider essentials for any JavaScript project:

1. Make code formatting consistent

Tool: Prettier Consistent code formatting reduces the "nitpicking" during code reviews and allows developers to focus on functionality. Prettier automatically formats your code based on defined rules.

Basic setup:

npm install --save-dev prettier

Add a .prettierrc configuration file for your rules:

{
  "semi": true,
  "singleQuote": false
}

Add a formatting script in your package.json:

"scripts": {
  "format": "prettier --write ."
}

2. Enforce best practices

Tool: eslint ESLint ensures your code adheres to best practices and project-specific conventions. With plugins, you can tailor it to your framework and project requirements.

Basic setup:

npm install --save-dev eslint

Initialize ESLint:

npx eslint --init

Install framework-specific plugins (e.g., Next.js):

npm install --save-dev eslint-config-next

Create a .eslintrc file for configuration or use the wizard setup.

3. Quick feedback on your changes

Tools: Husky + lint-staged Run linting and tests before committing or pushing code. This ensures only high-quality code is pushed to the repository.

Setup:

Install Husky and lint-staged:

npm install --save-dev husky lint-staged

Enable Husky hooks:

npx husky install

Add pre-commit and pre-push hooks:

npx husky add .husky/pre-commit "npx lint-staged"
npx husky add .husky/pre-push "npm run build"

Configure lint-staged in package.json:

"lint-staged": {
  "*.js": ["eslint --fix", "prettier --write", "jest --findRelatedTests"]
}

4. Pull-request static code analysis

Tool: SonarCloud Automates the detection of code smells, vulnerabilities, and potential bugs. Great for identifying issues early.

Setup:

Integrate SonarCloud into your CI pipeline using their documentation.

Add a sonar-project.properties file to configure the scanner.

5. Continuous integration (CI) pipeline

Tools: GitHub Actions, CircleCI, etc. Automate building and testing your code on every pull request.

Setup example with GitHub Actions:

Create a .github/workflows/ci.yml file:

name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
        timeout-minutes: 5
        strategy:
      matrix:
        node-version: [20.x]
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
      - name: Install Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: "npm"
      - name: Run build
        run: npm run build

      - name: Run unit tests
        run: npm run test

6. Continuous Deployment (CD) Pipeline

Deploy to staging and production automatically using tools like GitHub Actions or other CI/CD services. Testing in staging ensures environment variables and integrations work before going live.

Setup example for staging and production deployments:

Add a job to your CI pipeline to deploy after tests pass:

deployment:
    runs-on: ubuntu-latest
    timeout-minutes: 5
    strategy:
      matrix:
        node-version: [20.x]
    environment:
      name: ${{ github.ref == 'refs/heads/main' && 'production' || 'staging' }}
    needs:
      - integration
    if: always() && needs.integration.result == 'success'
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Install Node.js
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
          cache: "npm"

      - name: Install dependencies
        run: npm ci

      - name: Install serverless globally
        run: npm install serverless@3.38.0 --global

      - name: Serverless AWS authentication
        run: sls config credentials --provider aws --key ${{ secrets.AWS_ACCESS_KEY_ID }} --secret ${{ secrets.AWS_SECRET_ACCESS_KEY }}

      - name: Deploy API
        run: serverless deploy --stage $STAGE

7. End-to-End testing

Tools: Cypress, Playwright E2E tests ensure your application works as expected in a browser.

Setup example with Cypress:

Install Cypress:

npm install --save-dev cypress

Add a test script in package.json:

"scripts": {
  "test:e2e": "cypress open"
}

8. Use TypeScript for type safety and documentation

Tool: TypeScript TypeScript adds static typing to JavaScript, catching errors at compile time and improving code readability and maintainability.

Setup:

Install TypeScript:

npm install --save-dev typescript

Initialize a tsconfig.json file:

npx tsc --init

Update your scripts in package.json:

"scripts": {
  "build": "tsc"
}

Refactor your .js files to .ts and start enjoying type safety!

Adding these tools will significantly boost your project's maintainability and help your team focus on what matters most: building great features.

Make accessibility a default: Practical tips for Front-End developers

Viviane Dias — Mon, 04 Nov 2024 13:11:00 +0000

In the tech industry, tests have become a universal standard to gauge code quality and stability. Yet, one thing rarely makes the list: accessibility.

Accessibility is essential for ensuring that our software is usable by everyone, including users with disabilities or those navigating on different devices or in various environments. But because accessibility can seem complex and full of rules, many developers feel put off by it.

This guide is here to change that. By taking a few practical steps, you can start incorporating accessibility into your work naturally and easily, making it a default part of your workflow—no deep expertise required. Let’s dive into a few essential tools and practices that will help you get started.

1. Unit testing with `testing-library`

One of the most straightforward ways to start making accessible applications is to use testing-library for unit testing. This library not only enables you to test the usability and internal logic of components, but it also makes it easier to account for accessibility.

In particular, testing-library encourages using the *byRole queries (e.g., getByRole) to select elements by their role. This practice mirrors how screen readers interact with content, helping ensure that your app is accessible to users relying on assistive technologies.

Here are some resources for diving deeper:

Bonus tip: Install the `testing-library` ESLint plugin

To help enforce best practices while writing tests, install the Testing Library ESLint Plugin. This plugin will prompt you to follow accessibility guidelines, helping you anticipate common mistakes when writing tests with testing-library. It’s a handy way to ensure you’re following best practices for the library and, by extension, for accessibility.

3. Automate accessibility testing with `cypress-axe`

If you’re looking to test accessibility on a page level, try using cypress-axe. This tool integrates with Cypress to provide end-to-end accessibility testing, flagging issues like contrast ratio problems or missing ARIA attributes in real-time.

Its just one line of code:

beforeEach(() => {
  cy.visit('http://localhost:9000')
  cy.injectAxe()
})

cypress-axe helps automate accessibility tests across your app’s entire workflow, making it easy to catch potential issues at every stage.

4. Be an ally alongside designers

As developers, we’re often not the ones creating the initial UI designs, but we play an important role in maintaining and advocating for accessible choices. It’s common to encounter design specifications that don't meet contrast requirements or other accessibility standards.

Engage with designers early in the development process. Share accessibility concerns with them, and suggest tools like Radix UI for design systems with accessible color palettes. These conversations can lead to better overall design, helping make sure accessibility standards are met from the start.

5. Accessibility Tools

If you’re interested in going deeper into accessibility testing, there are several tools that can support you:

Silktide: An easy-to-use browser extension for manual, but effective accessibility checks.
Lighthouse: A free tool built into Chrome’s DevTools that provides a high-level overview of your app’s accessibility strengths and weaknesses.

For a comprehensive list of accessibility tools, check out the W3C’s accessibility tools hub, where you can find tools to help you at every stage of accessibility testing.

These resources provide insight into the areas where your application may fall short, helping you prioritize fixes in a practical way.

Conclusion

This is not an exhaustive list but rather a few tools I’ve adopted as a frontend engineer. They make it easier to “shift left” on accessibility, incorporating it earlier in development without requiring expert-level knowledge.

Accessibility is about inclusion—it’s a means of creating software that’s usable by as many people as possible. By implementing these practices, you can make accessibility a natural part of your workflow without needing deep expertise or complex tools. With every accessible component, test, and page, you’re contributing to a more inclusive digital world.

Let’s aim for accessibility as the default, so that we’re not only building software but building it for everyone.

Lessons learned from a developer hiring process that I didn't pass

Viviane Dias — Sun, 21 Feb 2021 19:38:14 +0000

About a year ago I had to solve a challenge for a hiring process and I didn't pass. Time has gone by and I was curious about how I'd write this code today.

These do's and dont's are based on what I learned in the past year and understood as best practices for writing code.

But before anything, a little context. At the time that I did this interview, I was really into functional programming (and still am), but like anything you're learning for the first time, I had some misconceptions. For instance, believing that just because I isolated my concerns and all of the functions were decoupled I had "mastered functional programming and clean code".

But I couldn't have been more wrong. Because while I did have some of those good practices in use, I broke other basic principles of Clean Code. While I knew the core concepts of functional programming, I didn't master the basics first - and I strongly believe that if I did I would've passed that test.

KISS

Something that bothered me and made the process of understanding that script so much harder was the fact that I dealt with data only in arrays. For example:

// Considering that every user was related to a book review
const arr = [[user1, user1Review], [user2, user2Review]]

That led to this kind of code:

const getBestReview = users => {
  const rating = users.map(user => [
    ...[user[0], user[1].rating]
  ])
  const sortUsersByRating = rating.sort((a, b) => b[1] - a[1])
  return sortUsersByRating[0][0]
}

Now, don't get me wrong, this is not the end of the world but... what? I had to read this piece of code one or two times before I could understand it completely, and this is a major no-no.

I believe that code should be as closely related to a narrative as possible. That's what this particular piece of code violates. What's inside user[1]? I don't know. Only if I go back to the line where I call getBestReview() and pass users as a parameter, I'll have a better sense of it. This is what we should avoid.

By choosing to use arrays for the sake of performance I violated another rule we definitely should always follow, "Keep it simple, stupid!" (KISS).

This is a pretty straightforward line of thinking, so I won't spend too much time explaining what it means. But let's just say that I wouldn't be processing a lot of information to worry about this kind of thing at the moment. Just stick to what you know you've got right now, and keep the code simple!

What would've solved this problem quite easily would be to use arrays of objects. Like so:

const arr = [{user, review}, {user, review}]
const getBestReview = users => {
const sortUsersByRating = users.sort((a, b) => b.review.rating - a.review.rating)
  return sortUsersByRating[0].user
}

Variable names

Another thing that I noticed is that while the constant name is getBestReview() I didn't return the best review, but the user that had the highest rating review. That violates another good practice that is: Name your variables, your functions, classes, etc, according to what value or operation they perform/keep.

This is crucial for maintaining the other principle I introduced above, that the code we write should assimilate as closely as possible to how we would sound like if we tried to tell other people what that particular piece of code does. Therefore, take your time to name your variables!

Another topic connected with readability is how we pass our function parameters. Take this code:

calculateUserInfluence(
  getReviewRating(review, getUser(stdin)),
  getTypeOfReviews(stdin, ratings, goodRatings)
)

The function calculateUserInfluence() actually has a good name on it, considering what it does, but let's focus on the parameters that we are passing. First, we pass getReviewRating(), and assuming that it does what it seems to do (something that we noticed we can't trust), we also pass another function, getUser() as a parameter inside getReviewRating().

That made me pause for a moment, and go check what those functions return. Because of this moment where I went searching for extra meaning at four different places on the script, I already wasted some precious time.

This may appear small at this scale, but if we get used to this practice, the maintenance of a more complex system can become a difficult job.

But how can we solve it? Easy! Store those getReviewRating,getUser,getTypeOfReviews inside variables with names that provide more context on what those functions return and how that relates to the parameter that calculateUserInfluence needs. Like so:

const userFromInput = getUser(stdin)
const reviewRating = getReviewRating(review, userFromInput)
const reviewTypes = getTypeOfReviews(stdin, ratings, goodRatings)
calculateUserInfluence(
  reviewRating,
  reviewTypes
)

Separate your concerns

While I believed that because I used functions everywhere and passed almost everything through parameters I was writing code that followed the functional paradigm, I missed another important rule.

I wrote every function that was used to process the input and give an output in the same index.js file. And this violates another good practice that is: separate your concerns. Next I'll try to demonstrate what that means:

// index.js
const capitalizeFirstLetter = string => string.charAt(0).toUpperCase() + string.slice(1)

const getBestReview = users => {
  const sortUsersByRating = users.sort((a, b) => b.review.rating - a.review.rating)
  return capitalizeFirstLetter(sortUsersByRating[0].user.name)
}

If the purpose of the challenge was to get the highest rating review from a list of users, I shouldn't include a helper function like capitalizeFirstLetter() inside the same file.

They should be separated so when reading the code for the first time, that helper method wouldn't pollute the readability of my script.

Separating concerns also helps in the understanding of your code, so the next developer that needs to work on a particular section of the business logic to add a new feature or even find a bug will have a much easier job while doing so.

Pro tip

Typescript

This isn't a must, but a little sprinkle of salt on top of a sweet recipe.

Something that I also missed while reading the code was a bit more context about the function parameters. While this is a problem that could've been avoided by using JSDoc, I prefer using Typescript because it also serves as a static type checker.

So Typescript would solve two of our issues:

Documentation
Static type checking

These advantages help us to improve our code maintainability and delivery confidence. In the long run, understanding every i/o in each method is much simpler with Typescript because it forces you to provide more context in each value that's being expected on those parameters, and what it returns.

Conclusion

When I submitted the challenge I was pretty confident that I'd pass the test. I used:

Principles of functional programming
Wrote tests that covered the entire script
Clean code (...)

But my code lacked some very basic principles like:

KISS
Good variable names
Separate the business logic from other methods

Studying the functional paradigm did give me a new perspective on writing code and nudged me in the right direction to improve my coding skills, considering that it forces you to be more aware of important things like:

Single responsibility principle
DRY (Don't repeat yourself)
TDD (Test-driven development)

But I lacked some very basic ones that for sure demonstrated my lack of experience at the time. If there's one piece of advice that I'd like to send with this article is this: Understand the importance of basic code principles, those will make you stand out more than saying that you apply fancy paradigms to your code.

Upload de Imagens com Integração Front/Back-End utilizando Stack MERN (Parte 1/2)

Viviane Dias — Mon, 23 Sep 2019 00:07:00 +0000

Enquanto desenvolvia um projeto há um tempo atrás, precisei fazer um upload de imagens integrar um formulário de cadastro. Achei pouquíssímos artigos que falassem sobre o assunto e também funcionassem do modo como eu precisava. Por fim, consegui realizar o que inicialmente estava à procura e resolvi escrever esse artigo para compartilhar alguns truques que aprendi no processo. As tecnologias utilizadas nesse tutorial são: NodeJS e MongoDB.

Visão Geral

O objetivo desse artigo é criar um app que consiga criar usuários e depois mostrar seu perfil em uma página. É algo simples, porém com um diferencial: um campo de upload de imagens no front, com um servidor que salva essa imagem no banco de dados e depois consegue buscá-la e retorná-la novamente.

O que vai ser usado aqui não é exclusivo para esse caso (criação de perfil), mas algo mais generalista e que pode ser usado em diferentes situações. Optei por não mostrar apenas as funções que fazem o upload mas sim todo o processo, pois senti que a parte de integração é uma peça fundamental para esse fluxo, e que não aparecia em nenhum artigo.

O método de upload é simples e possivelmente não é a melhor opção para apps que possuem uma grande demanda de upload de imagens, mas se você está fazendo apenas um webapp simples ou projeto pessoal, acredito que esse artigo seja para você! Os passos serão os seguintes:

Instalar dependências
Scripts
Estruturação do projeto
Setup MongoDB
Editando server.js
Modelos
- Imagens
- Users
Rotas
- Básico
- Criar usuário
- Buscar usuário
- Upload da imagem
Conclusão

Setup do back-end

Primeiro vá até a pasta em que você deseja guardar o projeto, no meu caso:


 shell
cd ~/Documents/programming/photo-upload-tutorial/photo-upload

Próximo passo é inicializar o projeto com o comando npm init. Esse comando irá criar um .json com várias informações sobre o app, mas, principalmente, irá guardar as bibliotecas necessárias para a execução dele posteriormente. Após executar o comando algumas perguntas serão feitas pelo terminal, preencha como você preferir, o meu ficou assim:

Instalar dependências

Depois de disso, instale as dependências que utilizaremos no projeto:


 shell
npm i body-parser cors express helmet mongoose multer --save


 shell
npm i nodemon --save-dev

Explicando um pouco sobre os comandos utilizados:

i: Installar
--save: Salvar as bibliotecas no arquivo package.json para caso outra pessoa queira também executar esse projeto, todas as bibliotecas usadas já estarão lá.
--save-dev: Muito parecido com o anterior, mas nesse caso essa biblioteca só será instalada no modo de desenvolvimento.

Scripts

Agora para os scripts! No momento apenas o script "test" existe. Vamos adicionar mais dois e seu objeto scripts no package.json deve ficar assim:



  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "node server.js",
    "server": "nodemon server.js"
  }

Estruturação do projeto

A seguir, crie todas as pastas e arquivos necessários para estruturar o app. Faça de acordo com o esquema a seguir:

photo-upload/
├── client/
├── config/
│ └── db.js
│ └── keys.js
├── models/
│ └── Images.js
│ └── Users.js
├── public/
│ └── uploads/
├── routes/
│ └── api/
│ └── users.js
├── server.js
└── package.json

Setup MongoDB

Nessa parte vamos configurar nosso banco de dados utilizando MongoDB.

Criando o banco de dados

Não pretendo entrar em detalhes sobre a instalação do Mongo, mas uma dica são os tutoriais dos docs que são bem detalhados. Depois de instalado, no terminal execute os seguintes comandos:

Para accesar o terminal do MongoDB



mongo

Criar/acessar o novo banco de dados



use nome-do-banco

Inserindo dados no banco para ele aparecer na listagem



db.nome-do-banco.insert({ "user": "qualquer nome" });

Vendo se o banco aparece na lista de bancos de dados disponíveis



show dbs

Criando um novo usuário


 shell
db.createUser({
  user: "nome do usuário que vai acessar o seu banco de dados",
  pwd: "senha do usuário p/ acessar o banco de dados",
  roles:[{
    role: "readWrite",
    db: "nome do banco de dados que esse usuário terá acesso"
  }]
})

Conectando servidor e banco de dados

Após a criação do banco, precisamos conectá-lo com o servidor. Para isso, vá até o arquivo db.js e insira:



const mongoose = require('mongoose')
const keys = require('./keys')

const MONGO_USERNAME = '[nome do usuário que você criou anteriormente]'
const MONGO_PASSWORD = keys.dbPassword
const MONGO_HOSTNAME = 'localhost'
const MONGO_PORT = '27017'
const MONGO_DB = '[nome do banco de dados criado anteriormente]'

const url = `mongodb://${MONGO_USERNAME}:${MONGO_PASSWORD}@${MONGO_HOSTNAME}:${MONGO_PORT}/${MONGO_DB}`

// Conectar com MongoDB
mongoose
  .connect(url, { useNewUrlParser: true })
  .then(() => console.log('MongoDB Connected'))
  .catch(err => console.log(err))

Note que em MONGO_PASSWORD foi setado uma variável, isso porque não é uma boa prática de segurança publicar senhas de bancos de dados ou API's em repositórios. Em vista disso, setei a senha do banco em um outro arquivo chamado keys.js que não é rastreado pelo git (caso adicionado ao .gitignore) e não sobe para o repositório remoto, ficando apenas no local.



  module.exports = {
    dbPassword: "senha do usuário para acessar o banco",
  }

Editando `server.js`

Como já criamos a estrutura básica para o nosso app, vá até o server.js e adicione o código base que irá rodar a aplicação, chamar as rotas e o banco de dados, além de setar mais alguns detalhes.



  const express = require('express')
  const bodyParser = require('body-parser')
  const cors = require('cors')
  const helmet = require('helmet')
  const db = require('./config/db')

  const users = require('./routes/api/users')

  // Executando express
  const app = express()

  // Middleware do body parser
  app.use(bodyParser.urlencoded({ extended: false }))
  app.use(bodyParser.json())

  // Adicionando Helmet para melhorar a segurança da API
  app.use(helmet())

  // Habilitando CORS para todos os requests
  app.use(cors())

  // Usar Routes
  app.use('/api/users', users)

  // Acessar arquivos de imagem salvos
  app.use(express.static('public'))

  // Definir porta que o app irá rodar
  const port = process.env.PORT || 5000
  app.listen(port, () => console.log(`Server running on port ${port}`))

Modelos

Precisamos salvar os dados preenchidos no formulário do front-end em algum lugar, para isso setamos Schemas no servidor que vão se conectar e salvar esses dados no banco de dados, para que assim possamos buscá-los posteriormente. Nesse projeto vamos criar dois, um para os usuários e outro para as imagens, para isso, altere os dois arquivos com os conteúdos correspondentes abaixo:

Users



const mongoose = require('mongoose')
const Schema = mongoose.Schema

// Criar Schema
const UserSchema = new Schema({
  name: {
    type: String,
    required: true
  },
  username: {
    type: String,
    required: true,
    unique: true
  },
  imgId: {
    type: Schema.Types.ObjectId,
    required: true
  },
  description: {
    type: String,
    required: true
  },
  location: {
    type: String,
    required: true,
  },
  createdAt: {
    type: Date,
    default: Date.now
  }
})

module.exports = User = mongoose.model('users', UserSchema)

Images



const mongoose = require('mongoose')
const Schema = mongoose.Schema

// Criar Schema relacionado ao Users, através do userId
const ImageSchema = new Schema({
  fieldname: {
    type: String,
    required: true
  },
  originalname: {
    type: String,
    required: true
  },
  encoding: {
    type: String,
    required: true
  },
  mimetype: {
    type: String,
    required: true
  },
  destination: {
    type: String,
    required: true
  },
  filename: {
    type: String,
    required: true
  },
  path: {
    type: String,
    required: true
  },
  size: {
    type: String,
    required: true
  },
  createdAt: {
    type: Date,
    default: Date.now
  }
})

module.exports = Images = mongoose.model('images', ImageSchema)

Rotas

Com os modelos definidos, partiremos para um dos momentos mais cruciais para que a aplicação funcione: A criação das rotas. Nesse projeto vamos criar quatro rotas, e cada uma delas será executada após ser chamada pelo client com um método HTTP específico. Elas estarão dentro do arquivo routes/api/users.js e serão estas:

Cria o usuário (POST)
Busca o usuário (GET)
Salva imagem (POST)
Busca imagem (GET)

Básico

Importe todos os arquvios e bibliotecas necessárias no arquvio routes/api/users.js




  const express = require('express')
  const router = express.Router()
  const multer = require('multer')
  const path = require('path')

  // Carregar modelo User
  const User = require('../../models/Users')
  // Carregar modelo Images
  const Images = require('../../models/Images')

  [restante do codigo]

  module.exports = router

Cria o usuário



// @route   POST api/users/register
// @desc    Register user
// @access  Public
router.post('/register', (req, res) => {
  let errors = {}
  User.findOne({ username: req.body.username })
    .then(user => {
      // Caso já exista um usuário com esse username, ele retorna um erro
      if (user) {
        errors.username = 'Esse username já foi usado'
        return res.status(400).json(errors)
      } else {
        const newUser = new User({
          name: req.body.name,
          username: req.body.username,
          imgId: req.body.imgId,
          description: req.body.description,
          location: req.body.location
        })
        newUser.save()
          .then(user => res.json(user))
          .catch(err => {
            // Caso dê um erro ao buscar usuário, a api retorna um erro
            console.log(err);
            res.status(404).json({ user: 'Erro ao salvar usuário' })
          })
      }
    })
    .catch(err => {
      // Caso dê um erro ao buscar usuário, a api retorna um erro
      console.log(err);
      res.status(404).json({ user: 'Erro ao cadastrar usuário' })
    })
})

Busca o usuário



// @route   GET api/users/:username
// @desc    Buscar usuário pelo username
// @access  Public
router.get('/:username', (req, res) => {
  const errors = {}
  User.findOne({ username: req.params.username })
    .then(user => {
      // Caso não haja nenhum usuário com esse username, a api retorna um erro
      if (!user) {
        errors.nousers = 'Esse usuário não existe'
        res.status(404).json(errors)
      }
      // Retorna o usuário
      res.json(user)
    })
    .catch(err => {
      // Caso dê um erro ao buscar usuário, a api retorna um erro
      console.log(err);
      res.status(404).json({ user: 'Erro ao buscar usuário' })
    })
})

Upload da imagem

Para fazer o upload usaremos o multer, um package que facilita esse processo ao fornecer funções prontas que nos ajudam a setar onde essas fotos serão armazenadas, filtros de tipos de extensão aceitas, se queremos apenas um upload por vez ou vários, etc.



const upload = multer({
  storage: storage,
  limits: {
    fileSize: 5000000
  },
  fileFilter: function (req, file, cb) {
    checkFileType(file, cb)
  }
}).single('img')

// Check file type
const checkFileType = (file, cb) => {
  // Allow ext
  const fileTypes = /jpeg|jpg|png|gif/

  // Check ext
  const extname = fileTypes.test(path.extname(file.originalname).toLowerCase())
  // Check mime
  const mimetype = fileTypes.test(file.mimetype)
  if (mimetype && extname) {
    return cb(null, true)
  } else {
    cb('Erro: Insira apenas imagens')
  };
}

Então descrevemos como essa chamada POST irá funcionar



// @route   POST api/users/upload
// @desc    Upload img usuário
// @access  Public
router.post('/upload', (req, res) => {
  upload(req, res, (err) => {
    const errors = {}

    // Caso haja erro no upload, cair aqui
    if (err) {
      errors.upload = err
      return res.status(404).json(errors)
    }

    // Caso o usuário não insira n  enhuma imagem e tente fazer upload, cair aqui
    if (!req.file) {
      errors.upload = 'Insira uma foto de perfil'
      return res.status(400).json(errors)
    }

    // Salvar img
    new Images(req.file)
      .save()
      .then(img => res.json({
        msg: 'Upload da imagem foi bem sucedido!',
        file: `uploads/${img.filename}`,
        id: img._id
      }))
      .catch(() => {
        errors.upload = 'Ocorreu um erro ao fazer o upload da imagem'
        res.status(404).json(errors)
      })
  })
})

Depois, como buscar essa imagem no banco e retonar ela como um `.json`



// @route   GET api/users/image
// @desc    Buscar img usuário
// @access  Public
router.get('/image/:imgId', (req, res) => {
  const errors = {}
  Images.findById(req.params.imgId)
    .then(img => {
      res.send(img)
    })
    .catch(() => {
      errors.upload = 'Ocorreu um erro ao carregar a imagem'
      res.status(404).json(errors)
    })
})

Conclusão

Pronto! Sua API está pronta e já pode ser testada :) Para rodar o servidor, execute npm run server dentro da pasta do projeto. Para facilitar o teste, vou colocar aqui as chamadas completas, seus métodos HTTP e body (quando for um POST).

Salva imagem

(POST) localhost:5000/api/users/upload

Caso você esteja testando em um programa como o Postman, aqui o key pode ser qualquer um e o value precisa ser uma imagem (file) com um dos tipos que foram setados na função checkFileType(). Depois que o upload for bem sucedido, guarde o id da imagem pois ele vai ser útil para o body do cadastro de usuário, se você quiser testá-lo. Além de um retorno bem sucedido da API, para saber se a imagem foi de fato salva você pode checar se ela está na pasta public/uploads/.

Busca imagem

(GET) localhost:5000/api/users/image/:imgId

Cria o usuário

(POST) localhost:5000/api/users/register


 javascript
{
  "name": "Vivi",
  "imgId": "5d87ace32732d74ba134bca5",
  "description": "Meu nome é Viviane, tenho 21 anos e amo tomar café depois do almoço ;)",
  "location": "São Paulo",
  "username": "vivianedias"
}

Busca o usuário

(GET) localhost:5000/api/users/:username

Antes de concluir gostaria de chamar atenção para uma parte em específico desse código. No arquivo server.js adicionamos uma linha que é crucial para o funcionameto do app:



app.use(express.static('public'))

O que essa linha faz é tornar a pasta /public uma rota estática para que posteriormente possamos consumir as imagens guardadas ali dentro, no front!

Bom, com isso concluímos a primeira parte desse artigo, o front-end sai logo menos :) Espero que vocês tenham gostado, sugestões e dúvidas são bem-vindas, e todo o código desse artigo vai estar aqui.

DEV Community: Viviane Dias

Key behaviors that got me promoted to Senior developer

1. Communicate clearly

How to succeed:

2. Make your work visible

Track your progress:

Why it matters:

3. Get involved

4. Dive into Technical Analysis

Benefits:

5. Start leading projects

Steps to get started:

Final thoughts

8 essentials for every JavaScript project

1. Make code formatting consistent

2. Enforce best practices

3. Quick feedback on your changes

4. Pull-request static code analysis

5. Continuous integration (CI) pipeline

6. Continuous Deployment (CD) Pipeline

7. End-to-End testing

8. Use TypeScript for type safety and documentation

Make accessibility a default: Practical tips for Front-End developers

1. Unit testing with testing-library

Bonus tip: Install the testing-library ESLint plugin

3. Automate accessibility testing with cypress-axe

4. Be an ally alongside designers

5. Accessibility Tools

Conclusion

Lessons learned from a developer hiring process that I didn't pass

KISS

Variable names

Separate your concerns

Pro tip

Typescript

Conclusion

Upload de Imagens com Integração Front/Back-End utilizando Stack MERN (Parte 1/2)

Visão Geral

Setup do back-end

Instalar dependências

Explicando um pouco sobre os comandos utilizados:

Scripts

Estruturação do projeto

Setup MongoDB

Criando o banco de dados

Para accesar o terminal do MongoDB

Criar/acessar o novo banco de dados

Inserindo dados no banco para ele aparecer na listagem

Vendo se o banco aparece na lista de bancos de dados disponíveis

Criando um novo usuário

Conectando servidor e banco de dados

Editando server.js

Modelos

Users

Images

Rotas

Básico

Cria o usuário

Busca o usuário

Upload da imagem

Então descrevemos como essa chamada POST irá funcionar

Depois, como buscar essa imagem no banco e retonar ela como um .json

Conclusão

Salva imagem

Busca imagem

Cria o usuário

Busca o usuário

1. Unit testing with `testing-library`

Bonus tip: Install the `testing-library` ESLint plugin

3. Automate accessibility testing with `cypress-axe`

Editando `server.js`

Depois, como buscar essa imagem no banco e retonar ela como um `.json`