<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های Farhad Adeli</title>
        <link>https://virgool.io/feed/@adeli.farhad</link>
        <description></description>
        <language>fa</language>
        <pubDate>2026-06-16 05:07:18</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/1312608/avatar/MuQjYp.jpg?height=120&amp;width=120</url>
            <title>Farhad Adeli</title>
            <link>https://virgool.io/@adeli.farhad</link>
        </image>

                    <item>
                <title>Why should your API not return database models directly?</title>
                <link>https://virgool.io/@adeli.farhad/why-should-your-api-not-return-database-models-directly-kdqrxpjmevjq</link>
                <description>Backend interview question:Why should your API not return database models directly?A common junior answer is:“Because it works and it is faster to develop.”And honestly, for a small prototype, that might be fine.But in real production systems, returning database models directly can create problems very quickly.For example, your User table may have fields like:passwordHash
resetToken
internalNotes
roleId
createdBy
deletedAtEven if you “hide” some fields today, the risk is still there.The bigger problem is coupling.When your API response is the same shape as your database model, every database change can accidentally become an API change.That means:Frontend becomes tightly coupled to backend internalsRefactoring the database becomes riskySensitive fields may leak by mistakeAPI versioning becomes harderYour response shape is designed around storage, not user needsA better approach is to use DTOs or response mappers.The database model answers:“How do we store this data?”The API response should answer:“What does the client actually need?”That small separation makes your system much easier to maintain as it grows.Senior backend development is not just about making the endpoint work.It is about protecting future changes.How do you usually structure API responses in your projects?#NodeJS #BackendDevelopment #APIDesign #TypeScript #SoftwareEngineering #FullStackDevelopment</description>
                <category>Farhad Adeli</category>
                <author>Farhad Adeli</author>
                <pubDate>Sun, 14 Jun 2026 05:47:55 +0330</pubDate>
            </item>
                    <item>
                <title>When would you use container queries instead of media queries?</title>
                <link>https://virgool.io/@adeli.farhad/when-would-you-use-container-queries-instead-of-media-queries-gxv2qwq1ntvj</link>
                <description>Frontend interview question:A lot of developers answer:“Media queries are for responsive design.”True, but incomplete.Media queries respond to the screen size.Container queries respond to the actual size of the component’s parent/container.That difference matters a lot when you build reusable components.For example, imagine a ProductCard component.On one page, it is inside a 3-column grid.On another page, it is inside a narrow sidebar.On another page, it is inside a dashboard widget.The screen size may be the same, but the available space for the component is completely different.That is where container queries are much cleaner.Instead of asking:“Is the viewport smaller than 768px?”You ask:“How much space does this component actually have?”My rule of thumb:Use media queries for page-level layout.Use container queries for reusable components.This avoids a lot of layout bugs when the same component is reused in different places.Senior frontend development is not just about making things responsive.It is about making components survive real-world reuse.How would you explain this in an interview?#FrontendDevelopment #CSS #WebDevelopment #ReactJS #Angular #VueJS #SoftwareEngineering</description>
                <category>Farhad Adeli</category>
                <author>Farhad Adeli</author>
                <pubDate>Sun, 14 Jun 2026 05:34:36 +0330</pubDate>
            </item>
                    <item>
                <title>React performance problems</title>
                <link>https://virgool.io/@adeli.farhad/react-performance-problems-vpsxdpqnzhmq</link>
                <description>Most React performance problems are not fixed with useMemo.A lot of developers see a component re-rendering and immediately reach for:useMemo()
useCallback()
React.memo()But in many cases, that just makes the code more complex without solving the real problem.The better question is not:“How do I stop this component from re-rendering?”The better question is:“Why is this component receiving changes it does not actually need?”In my experience, most React performance issues come from:State living too high in the component treePassing unstable objects/functions as propsContext providers wrapping too much of the appComponents doing too many unrelated jobsRendering large lists without virtualizationuseMemo can help, but it should usually be the second or third solution — not the first one.A simple rule I use:Before optimizing a component, first fix the data flow.Clean architecture beats random memoization almost every time.What is your usual first step when a React component becomes slow?#ReactJS #FrontendDevelopment #JavaScript #WebDevelopment #SoftwareEngineering</description>
                <category>Farhad Adeli</category>
                <author>Farhad Adeli</author>
                <pubDate>Fri, 12 Jun 2026 17:18:39 +0330</pubDate>
            </item>
            </channel>
</rss>